Dependency Injection in EF Core

In this lesson, you will learn how to precisely register your DbContext lifetimes and configurations within complex Dependency Injection (DI) containers to ensure your application remains stable and scalable.

Managing DbContext Lifetimes

In complex applications, how you register your DbContext determines how your application handles database connections and state tracking. By default, AddDbContext registers the context as Scoped. This is the "sweet spot" for most web applications: a single instance is created per HTTP request, ensuring that all services involved in that request share the same unit of work and state.

When working with complex DI containers, you might need to register the context differently if you are building background workers or multi-threaded services. For instance, you can explicitly define the lifetime when registering:

services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString),
    ServiceLifetime.Scoped, // Default
    ServiceLifetime.Singleton // Or Transient, depending on your architecture
);

Advanced Configuration Injection

In sophisticated setups, your DbContext might require configurations from other services (like an IConfiguration or a custom IConnectionStringProvider). Instead of hardcoding your connection string, you can resolve dependencies during the registration process:

services.AddDbContext<AppDbContext>((serviceProvider, options) =>
{
    var config = serviceProvider.GetRequiredService<IConfiguration>();
    var connectionString = config.GetConnectionString("DefaultConnection");
    
    options.UseSqlServer(connectionString)
           .EnableSensitiveDataLogging(); // Only in Dev!
});

By using the serviceProvider overload, you decouple the database configuration from the start-up logic. This allows your DbContext to dynamically adapt to different environments (e.g., development, staging, or production) without manual intervention.

When designing large-scale systems, always be mindful of the DbContext lifetime. If you inject a Scoped context into a Singleton service, you create a "captive dependency," where the context lives as long as the singleton service, leading to stale data and potential thread-safety issues. Always ensure that your DbContext remains scoped to the natural boundary of your work, typically a request or a background task execution.

Key Takeaway: Use the AddDbContext factory overload to inject necessary dependencies into your configuration, and always match your DbContext lifetime to the intended scope of your application’s work units to avoid state corruption.