Dependency Injection Patterns

When to Use This Skill

Use this skill when:

• Organizing service registrations in ASP.NET Core applications

• Avoiding massive Program.cs/Startup.cs files with hundreds of registrations

• Making service configuration reusable between production and tests

• Designing libraries that integrate with Microsoft.Extensions.DependencyInjection

Reference Files

• advanced-patterns.md: Testing with DI extensions, Akka.NET actor scope management, conditional/factory/keyed registration patterns

The Problem

Without organization, Program.cs becomes unmanageable:

// BAD: 200+ lines of unorganized registrations var builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<IUserRepository, UserRepository>(); builder.Services.AddScoped<IOrderRepository, OrderRepository>(); builder.Services.AddScoped<IProductRepository, ProductRepository>(); builder.Services.AddScoped<IUserService, UserService>(); // ... 150 more lines ...

Problems: hard to find related registrations, no clear boundaries, can't reuse in tests, merge conflicts.

The Solution: Extension Method Composition

Group related registrations into extension methods:

// GOOD: Clean, composable Program.cs var builder = WebApplication.CreateBuilder(args);

builder.Services .AddUserServices() .AddOrderServices() .AddEmailServices() .AddPaymentServices() .AddValidators();

var app = builder.Build();

Extension Method Pattern

Basic Structure

namespace MyApp.Users;

public static class UserServiceCollectionExtensions { public static IServiceCollection AddUserServices(this IServiceCollection services) { services.AddScoped<IUserRepository, UserRepository>(); services.AddScoped<IUserReadStore, UserReadStore>(); services.AddScoped<IUserWriteStore, UserWriteStore>(); services.AddScoped<IUserService, UserService>(); services.AddScoped<IUserValidationService, UserValidationService>();

    return services;
}

}

With Configuration

namespace MyApp.Email;

public static class EmailServiceCollectionExtensions { public static IServiceCollection AddEmailServices( this IServiceCollection services, string configSectionName = "EmailSettings") { services.AddOptions<EmailOptions>() .BindConfiguration(configSectionName) .ValidateDataAnnotations() .ValidateOnStart();

    services.AddSingleton<IMjmlTemplateRenderer, MjmlTemplateRenderer>();
    services.AddSingleton<IEmailLinkGenerator, EmailLinkGenerator>();
    services.AddScoped<IUserEmailComposer, UserEmailComposer>();
    services.AddScoped<IEmailSender, SmtpEmailSender>();

    return services;
}

}

File Organization

Place extension methods near the services they register:

src/ MyApp.Api/ Program.cs # Composes all Add* methods MyApp.Users/ Services/ UserService.cs UserServiceCollectionExtensions.cs # AddUserServices() MyApp.Orders/ OrderServiceCollectionExtensions.cs # AddOrderServices() MyApp.Email/ EmailServiceCollectionExtensions.cs # AddEmailServices()

Convention: {Feature}ServiceCollectionExtensions.cs next to the feature's services.

Naming Conventions

Pattern Use For

Add{Feature}Services()

General feature registration

Add{Feature}()

Short form when unambiguous

Configure{Feature}()

When primarily setting options

Use{Feature}()

Middleware (on IApplicationBuilder)

Testing Benefits

The Add* pattern lets you reuse production configuration in tests and only override what's different. Works with WebApplicationFactory, Akka.Hosting.TestKit, and standalone ServiceCollection.

See advanced-patterns.md for complete testing examples.

Layered Extensions

For larger applications, compose extensions hierarchically:

public static class AppServiceCollectionExtensions { public static IServiceCollection AddAppServices(this IServiceCollection services) { return services .AddDomainServices() .AddInfrastructureServices() .AddApiServices(); } }

public static class DomainServiceCollectionExtensions { public static IServiceCollection AddDomainServices(this IServiceCollection services) { return services .AddUserServices() .AddOrderServices() .AddProductServices(); } }

Akka.Hosting Integration

The same pattern works for Akka.NET actor configuration:

public static class OrderActorExtensions { public static AkkaConfigurationBuilder AddOrderActors( this AkkaConfigurationBuilder builder) { return builder .WithActors((system, registry, resolver) => { var orderProps = resolver.Props<OrderActor>(); var orderRef = system.ActorOf(orderProps, "orders"); registry.Register<OrderActor>(orderRef); }); } }

// Usage in Program.cs builder.Services.AddAkka("MySystem", (builder, sp) => { builder .AddOrderActors() .AddInventoryActors() .AddNotificationActors(); });

See akka-hosting-actor-patterns skill for complete Akka.Hosting patterns.

Anti-Patterns

Don't: Register Everything in Program.cs

// BAD: Massive Program.cs with 200+ lines of registrations

Don't: Create Overly Generic Extensions

// BAD: Too vague, doesn't communicate what's registered public static IServiceCollection AddServices(this IServiceCollection services) { ... }

Don't: Hide Important Configuration

// BAD: Buried settings public static IServiceCollection AddDatabase(this IServiceCollection services) { services.AddDbContext<AppDbContext>(options => options.UseSqlServer("hardcoded-connection-string")); // Hidden! }

// GOOD: Accept configuration explicitly public static IServiceCollection AddDatabase( this IServiceCollection services, string connectionString) { services.AddDbContext<AppDbContext>(options => options.UseSqlServer(connectionString)); }

Best Practices Summary

Practice Benefit

Group related services into Add* methods Clean Program.cs, clear boundaries

Place extensions near the services they register Easy to find and maintain

Return IServiceCollection for chaining Fluent API

Accept configuration parameters Flexibility

Use consistent naming (Add{Feature}Services ) Discoverability

Test by reusing production extensions Confidence, less duplication

Lifetime Management

Lifetime Use When Examples

Singleton Stateless, thread-safe, expensive to create Configuration, HttpClient factories, caches

Scoped Stateful per-request, database contexts DbContext, repositories, user context

Transient Lightweight, stateful, cheap to create Validators, short-lived helpers

// SINGLETON: Stateless services, shared safely services.AddSingleton<IMjmlTemplateRenderer, MjmlTemplateRenderer>();

// SCOPED: Database access, per-request state services.AddScoped<IUserRepository, UserRepository>();

// TRANSIENT: Cheap, short-lived services.AddTransient<CreateUserRequestValidator>();

Scoped services require a scope. ASP.NET Core creates one per HTTP request. In background services and actors, create scopes manually.

See advanced-patterns.md for actor scope management patterns.

Common Mistakes

Injecting Scoped into Singleton

// BAD: Singleton captures scoped service - stale DbContext! public class CacheService // Registered as Singleton { private readonly IUserRepository _repo; // Scoped - captured at startup! }

// GOOD: Inject IServiceProvider, create scope per operation public class CacheService { private readonly IServiceProvider _serviceProvider;

public async Task<User> GetUserAsync(string id)
{
    using var scope = _serviceProvider.CreateScope();
    var repo = scope.ServiceProvider.GetRequiredService<IUserRepository>();
    return await repo.GetByIdAsync(id);
}

}

No Scope in Background Work

// BAD: No scope for scoped services public class BadBackgroundService : BackgroundService { private readonly IOrderService _orderService; // Scoped - will throw! }

// GOOD: Create scope for each unit of work public class GoodBackgroundService : BackgroundService { private readonly IServiceScopeFactory _scopeFactory;

protected override async Task ExecuteAsync(CancellationToken ct)
{
    using var scope = _scopeFactory.CreateScope();
    var orderService = scope.ServiceProvider.GetRequiredService<IOrderService>();
    // ...
}

}

Resources

• Microsoft.Extensions.DependencyInjection: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection

• Akka.Hosting: https://github.com/akkadotnet/Akka.Hosting

• Akka.DependencyInjection: https://getakka.net/articles/actors/dependency-injection.html

• Options Pattern: See microsoft-extensions-configuration skill