Dependency Injection

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

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

public class OrderService {
    private readonly IEmailSender _emailSender;
    public OrderService(IEmailSender emailSender) => _emailSender = emailSender;  // auto-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 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 startup/resolution:
// "Cannot consume scoped service 'AppDbContext' from singleton 'INotificationService'"

// Correct fix: inject IServiceScopeFactory into the Singleton instead
// and create scopes on demand for each unit of work

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 {
    private readonly IEnumerable<INotifier> _notifiers;
    public NotificationService(IEnumerable<INotifier> notifiers) => _notifiers = 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 does 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 {
    public CheckoutService([FromKeyedServices("stripe")] IPaymentProcessor processor) {
        _processor = 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 OrderService {
    // Having two constructors like this causes issues with the built-in container:
    public OrderService(IEmailSender emailSender) { ... }
    public OrderService(IEmailSender emailSender, ILogger<OrderService> logger) { ... }
    // Built-in container: ambiguous, throws at resolution time
}
// Fix: use exactly one constructor, or use a third-party container supporting this

Common follow-ups: Which third-party containers (Autofac, etc.) do support multiple constructor resolution?;What's the recommended pattern instead of multiple constructors?

public class ReportGenerator : BackgroundService {
    private readonly IServiceScopeFactory _scopeFactory;
    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 and other scoped services cleaned up
}

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

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

// 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?

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?