Dependency Injection

public interface IEmailSender { Task SendAsync(string to, string body); }
public class SmtpEmailSender : IEmailSender { ... }

builder.Services.AddScoped<IEmailSender, SmtpEmailSender>();

public class OrderService(IEmailSender emailSender) {
    // emailSender is automatically injected
}

Common follow-ups: What are the three built-in service lifetimes and how do they differ?;How does DI relate to the broader Inversion of Control principle?

builder.Services.AddSingleton<ICacheService, MemoryCacheService>();  // one instance, app lifetime
builder.Services.AddScoped<AppDbContext>();                          // one instance per HTTP request
builder.Services.AddTransient<IEmailFormatter, EmailFormatter>();    // new instance every injection

Common follow-ups: What happens if a Singleton service depends on a Scoped service (captive dependency problem)?;How do you choose the right lifetime for a new service?

builder.Services.AddSingleton<INotificationService, NotificationService>();
builder.Services.AddScoped<AppDbContext>();

// NotificationService depending on AppDbContext throws at resolution:
// "Cannot consume scoped service 'AppDbContext' from singleton 'INotificationService'"

// Fix: inject IServiceScopeFactory into the Singleton and create scopes on demand instead

Common follow-ups: How do you fix a captive dependency once identified?;Why is scope validation enabled by default in Development but not always in Production?

builder.Services.AddScoped<INotifier, EmailNotifier>();
builder.Services.AddScoped<INotifier, SmsNotifier>();
builder.Services.AddScoped<INotifier, PushNotifier>();

public class NotificationService(IEnumerable<INotifier> notifiers) {
    public async Task NotifyAllAsync(string message) {
        foreach (var notifier in notifiers) await notifier.SendAsync(message);
    }
}

Common follow-ups: How do you resolve just the LAST registered implementation instead of all of them?;How do keyed services (added in .NET 8) provide a more explicit alternative to this pattern?

builder.Services.AddKeyedScoped<IPaymentProcessor, StripeProcessor>("stripe");
builder.Services.AddKeyedScoped<IPaymentProcessor, PayPalProcessor>("paypal");

public class CheckoutService([FromKeyedServices("stripe")] IPaymentProcessor processor) {
    // explicitly gets the Stripe implementation
}

Common follow-ups: How do keyed services interact with IEnumerable<T> injection -- can you still get all of them?;What's the migration path from a hand-rolled factory pattern to keyed services?

public class ReportGenerator(IServiceScopeFactory scopeFactory) : BackgroundService {
    protected override async Task ExecuteAsync(CancellationToken ct) {
        using var scope = scopeFactory.CreateScope();
        var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        await GenerateReportAsync(db);
    }  // scope disposed here, DbContext cleaned up
}

Common follow-ups: What happens to scoped services if you never dispose the created scope?;How does this differ from calling IServiceProvider.CreateScope() directly?

public class ReportExporter : IDisposable {
    public void Dispose() => Console.WriteLine("Disposed");
}

builder.Services.AddTransient<ReportExporter>();
// Even though Transient, if resolved many times within one request scope,
// ALL instances are held and disposed together only when that request scope ends

Common follow-ups: Why doesn't the container dispose Transient services immediately after use?;How would you work around this for a Transient disposable used many times in a loop?

builder.Services.AddScoped<IPaymentGateway>(sp => {
    var config = sp.GetRequiredService<IOptions<PaymentSettings>>().Value;
    return config.Provider switch {
        "stripe" => new StripeGateway(config.ApiKey),
        "paypal" => new PayPalGateway(config.ApiKey),
        _ => throw new InvalidOperationException("Unknown payment provider")
    };
});

Common follow-ups: How does this compare to using keyed services for the same conditional-provider scenario?;What services can you safely resolve inside a factory delegate without lifetime issues?

// Controller: constructor injection
public class ProductsController(IProductService service) : ControllerBase {
    [HttpGet] public IActionResult GetAll() => Ok(service.GetAll());
}

// Minimal API: parameter injection, inferred automatically
app.MapGet("/products", (IProductService service) => service.GetAll());

Common follow-ups: Does parameter-based injection have any measurable performance difference from constructor injection?;How does explicit [FromServices] disambiguate a service parameter from a route/body parameter?

// Preferred: constructor injection, dependencies explicit
public class OrderService(IEmailSender emailSender) { ... }

// Anti-pattern: service location, hidden dependency
public class OrderService {
    public void Process(IServiceProvider provider) {
        var emailSender = provider.GetService<IEmailSender>();  // hidden, hard to test
    }
}

Common follow-ups: When is service location actually the pragmatic right choice (like plugin systems)?;How does this relate to the broader Service Locator anti-pattern debate?