What is Dependency Injection & Service Lifetimes in ASP.NET Core?

Dependency Injection (DI) is a foundational design pattern in ASP.NET Core that revolutionizes how dependencies between classes are managed. Instead of classes creating their own dependencies, dependencies are provided to them externally. This approach promotes loose coupling, enhances testability, and simplifies maintenance. ASP.NET Core includes a built-in DI container (IServiceProvider) that automates dependency management, making it integral to modern .NET development.

Introduction to Dependency Injection in ASP.NET Core

Dependency Injection (DI) is a software design pattern in which an object receives (“has injected”) the objects it depends on, rather than creating them itself. In other words, DI inverts control by having an external container or framework provide a class’s dependencies. This leads to loosely coupled code: classes depend on interfaces or abstractions, not concrete implementations. In ASP.NET Core, DI is built in and enabled by default. Microsoft notes that “ASP.NET Core supports the dependency injection (DI) software design pattern” as a technique to achieve Inversion of Control between classes and their dependencies.

By using DI, an application separates the concerns of creating objects from using them. A class need not know how to construct its dependencies; it only declares the interfaces it needs. The ASP.NET Core DI container (part of IServiceProvider) takes on the responsibility of instantiating objects and passing them into classes (often via constructors) when needed. This makes code easier to maintain and test. For example, instead of tightly binding a class to a concrete type, you register the abstraction and its implementation with the DI container. Then at runtime, the framework injects the correct implementation automatically.

Figure-1: Dependency Injection in ASP.NET Core

The Problem: Tight Coupling

Consider a scenario without DI: if a controller or service uses new to create its dependencies, it becomes tightly coupled to those classes. Replacing or mocking that dependency would require changing the class itself. Also, configuration and object creation logic can become scattered throughout the app. ASP.NET Core documentation warns that this approach is problematic: “If MyDependency has dependencies, they must also be configured by the IndexModel class… In a large project with multiple classes depending on MyDependency, the configuration code becomes scattered”. DI solves these problems by using interfaces to abstract implementations, centralizing registration in a container, and having the framework inject instances as needed. 

So, without DI, classes directly instantiate dependencies, leading to:

• Rigid code: Changes in dependencies require modifying dependent classes.
• Testing difficulties: Mocking dependencies for unit tests becomes cumbersome.
• Code duplication: Dependency configuration scatters across the application.

// Problem: Manual dependency creation
public class ReportService
{
    private readonly ILogger _logger = new FileLogger(); // Tight coupling
}

Benefits of Dependency Injection

• Loose Coupling: Classes depend on interfaces or abstractions rather than concrete classes. This decoupling allows implementations to change without modifying consumer code. For instance, you could swap a real data repository with a mock for testing without altering the class that uses it.
  
  
• Testability: By injecting dependencies, it becomes easy to provide test doubles (mocks, stubs) during unit tests. A service that expects an interface can be passed a mock in a test context, isolating the code under test.
  
  
• Flexibility & Extensibility: DI makes it straightforward to extend functionality. New behaviors can be added by implementing interfaces and registering them, without altering existing classes. The DI container handles wiring them together.
  
  
• Lifecycle Management: ASP.NET Core’s built-in container manages object lifetimes (we’ll discuss lifetimes below), including disposal of disposable services when a request ends.
  
  
• Centralized Configuration: All service registrations happen in one place (typically in Program.cs), making it easy to view and modify dependencies in the app.
  
  

Overall, DI encourages better Separation of Concerns. Instead of each class being responsible for locating or creating its own resources, that responsibility is inverted and given to a container that injects the required services.

What is Inversion of Control (IoC)?

Inversion of Control is a broad principle where the control of object creation and lifecycle is transferred from the application to a container or framework. Dependency Injection is a specific implementation of IoC. 

Figure-2: Flow chart of IoC in ASP.NET Core

How Dependency Injection Works in ASP.NET Core?

In ASP.NET Core, dependency injection is part of the framework itself. The IServiceCollection (accessible via builder.Services or services in Startup) is used to register services and their lifetimes. At startup, you typically register all your application’s services with services.AddXxx<Interface, Implementation>(). Later, when the application runs, ASP.NET Core’s built-in service container (IServiceProvider) creates instances of registered services and injects them into constructors or methods.

Figure-3: Dependency Injection Process Flow in ASP.NET Core

The process typically involves three steps:

1. Define an Abstraction via Interfaces and implementation

Dependencies are abstracted behind interfaces or base classes. For example, create an interface ILogger and a class FileLogger that implements it:

public interface ILogger
{
    void Log(string message);
}

public class FileLogger : ILogger
{
    public void Log(string message) => /* ... */ 
}

2. Registration in the Service Container

Services are registered in In Program.cs or Startup.cs with explicit lifetimes, add a line like services.AddScoped<ILogger, FileLogger>();. This tells the container: “When someone needs ILogger, use FileLogger”:

...

builder.Services.AddScoped<ILogger, FileLogger>(); // Scoped per request

builder.Services.AddTransient<IEmailService, EmailService>(); // New instance each time

builder.Services.AddSingleton<ICacheService, CacheService>(); // Single instance app-wide

...

Here we use three common registration methods:

• AddScoped<ILogger, FileLogger>() – one instance of FileLogger is created per HTTP request (scope) and reused in that request.
  
  
• AddTransient<IEmailService, EmailService>() – a new instance of EmailService is created every time IEmailService is needed.
  
  
• AddSingleton<ICacheService, CacheService>() – a single instance of CacheService is created and used for the lifetime of the application.
  
  

Each of these methods maps an interface to a concrete class. After calling these, whenever a class needs ILogger (for example), ASP.NET Core will inject an instance of FileLogger from the container.

3. Use Constructor Injection

Dependencies are injected via class constructors. Any class (controller, middleware, Razor Page model, etc.) that needs ILogger can declare it as a constructor parameter. The framework will automatically resolve and pass in the registered FileLogger instance at runtime:

public class ReportService
{
    private readonly ILogger _logger;
    
    public ReportService(ILogger logger) // Injected dependency
    {
        _logger = logger;
    }
}

In the above, ASP.NET Core sees the constructor parameter ILogger logger and looks into the container to find a registered service for ILogger. It then passes an instance of FileLogger (or whichever class was registered) to the constructor. The controller never calls new FileLogger() itself; all that work is done by the framework.

What is Service Lifetimes?

When registering services, you specify a lifetime that determines how long an instance is reused. ASP.NET Core provides three main lifetimes:

Lifetime	Description	Use Case
Scoped	Single instance per HTTP request	Database contexts, per-request caching
Transient	New instance every time requested	Stateless services (e.g., lightweight calculators)
Singleton	Single instance for the app lifetime	Configuration services, global caching

• Scoped (AddScoped): A single instance is created per scope. In web apps, a scope is usually one HTTP request. So for each incoming HTTP request, one instance of the service is used across all uses in that request. This is common for things like database contexts (DbContext) where you want one context per request. E.g., services.AddScoped<IDatabase, SqlDatabase>().
  
  
• Transient (AddTransient): A new instance of the service is created every time it is requested. This is useful for lightweight, stateless services. For example, if you register services.AddTransient<IOrderProcessor, OrderProcessor>(), then every time the container needs IOrderProcessor, it will call new OrderProcessor().
  
  
• Singleton (AddSingleton): One instance is created the first time it’s requested, and that same instance is used for the lifetime of the application. All requests and threads get the same instance. Useful for stateless services or data that can be shared safely. Example: services.AddSingleton<IAppSettings, AppSettings>().
  
  

In practice, the choice of lifetime affects behavior. For example, if you use a transient lifetime for a service, each injection point gets a fresh copy, whereas with scoped or singleton you may get the same instance in multiple places.

Example usage:

...

// Scoped: one instance per HTTP request
builder.Services.AddScoped<IUserRepository, UserRepository>();


// Transient: new instance for every injection
builder.Services.AddTransient<IEmailSender, SmtpEmailSender>();


// Singleton: one shared instance for entire app
builder.Services.AddSingleton<ICacheService, MemoryCacheService>();

...

It’s important to choose the correct lifetime. Using a singleton for a service that depends on scoped services (like HttpContext or DbContext) can cause problems. Also, injecting a singleton that is not thread-safe can be dangerous in a web app.

Constructor Injection (Preferred Method)

ASP.NET Core’s DI container primarily uses constructor injection. This means dependencies are declared as constructor parameters. For example:

public class OrderController : Controller
{
    private readonly IOrderService _orderService;
    public OrderController(IOrderService orderService)
    {
        _orderService = orderService;  // injected by DI
    }

    public IActionResult Create(OrderModel model)
    {
        _orderService.PlaceOrder(model);
        return View();
    }
}

Here, IOrderService orderService in the constructor signals the DI system to supply an implementation of IOrderService when creating OrderController. The ASP.NET Core framework will do this automatically when routing to the controller. As the official docs note: “Injection of the service into the constructor of the class where it’s used. The framework takes on the responsibility of creating an instance of the dependency”.

Constructor injection has several advantages: it makes dependencies explicit, allows for required dependencies (the class won’t compile without them), and enables easy unit testing by passing in mocks.

Other Injection Techniques

While constructor injection is the most common and recommended method, there are other ways to use DI in ASP.NET Core:

• Method/Action Injection: In ASP.NET Core MVC or Razor Pages, action methods (or handler methods) can take services as parameters. The framework will inject services into action parameters as well. For example:
  
  

public IActionResult About([FromServices] IMyService myService)
{
    var data = myService.GetInfo();
    return View(data);
}



Using the [FromServices] attribute tells ASP.NET Core to resolve that parameter via DI. This is less common but available.


• Middleware Injection: For custom middleware, it’s recommended to inject services via the InvokeAsync method parameters, not through the middleware’s constructor, due to how the middleware lifetime works. Example:
  
  

public class MyMiddleware
{
    private readonly RequestDelegate _next;
    public MyMiddleware(RequestDelegate next) { _next = next; }
    public async Task InvokeAsync(HttpContext context, IMyService myService)
    {
        // myService is injected here
        await _next(context);
    }
}




• Property Injection: ASP.NET Core does not support property injection by default. You would have to manually retrieve services from IServiceProvider if needed, which is generally discouraged in favor of constructor injection.

In most cases, you should stick with constructor injection for clarity and simplicity.

Example: Putting It All Together

Let’s walk through a concrete example. Suppose we want to send notifications:

1.    Define an interface and implementation:

public interface INotifier
{
    void Notify(string message);
}

public class EmailNotifier : INotifier
{
    public void Notify(string message)
    {
        // Code to send an email
        Console.WriteLine($"Email sent: {message}");
    }
}

2.    Register the service in Program.cs:

...

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();


...

3.    Inject and use in a controller:

public class NotificationController : Controller
{
    private readonly INotifier _notifier;
    public NotificationController(INotifier notifier)
    {
        _notifier = notifier;
    }

    public IActionResult Notify(string msg)
    {
        _notifier.Notify(msg);
        return Ok("Notified!");
    }
}

 

Here, when a request comes in to NotificationController, ASP.NET Core sees that the constructor needs INotifier. It checks the container, finds EmailNotifier as the implementation (as per registration), creates an instance, and passes it to the controller. This happens automatically without any new calls in your code. The benefit is clear: you could later create a different class (e.g., SmsNotifier) that implements INotifier, and swap the registration without changing the controller code.

Additional Benefits of Dependency Injection: In Practice

Using DI in ASP.NET Core has many practical advantages:

• Easier Unit Testing: Since classes depend on interfaces, you can inject mocks during testing. For example, in a unit test for NotificationController, you could pass a fake INotifier that records messages instead of actually sending an email.
  
  
• Flexible Configuration: You can configure which implementation to use at startup. Even choose different implementations based on environment (e.g., development vs production).
  
  
• Scalable Architecture: DI supports building layered architectures. For example, a web layer depends on a service layer, which depends on a repository layer. Each layer only knows the interfaces of the layer below. The DI container manages the object graph.
  
  
• Built-in Framework Services: ASP.NET Core itself uses DI for its own services (logging, configuration, HTTP context, etc.), so you can inject framework-provided services as well. For instance, controllers can request ILogger<MyController> or IConfiguration out of the box with no extra registration.
  
  
• Chained DI: It’s common to have chains of dependencies. As one example, the Microsoft docs show a MyDependency2 class that itself depends on ILogger<T>; the container resolves logger generically. The container even handles generic services like ILogger<T> without explicit registration.
  
  

Common Patterns and Best Practices

• Constructor Over Inversion of Control: Always prefer having dependencies passed in via constructors (constructor injection) rather than using the Service Locator pattern (calling HttpContext.RequestServices.GetService inside classes). Constructor injection keeps code cleaner and more testable.
  
  
• Avoid Service Locator: The Service Locator anti-pattern (scavenging a global container for services) hides dependencies and makes code harder to follow.
  
  
• Group Registrations: It’s common to create extension methods on IServiceCollection to encapsulate registering related services. For example:
  
  
  

public static class MyFeatureServiceExtensions
{
    public static IServiceCollection AddMyFeatureServices(this IServiceCollection services)
    {
        services.AddScoped<IFoo, Foo>();
        services.AddScoped<IBar, Bar>();
        return services;
    }
}

// Then in Program.cs:
builder.Services.AddMyFeatureServices();




• Options Pattern: ASP.NET Core also uses DI to inject configured options. You can services.Configure<MyOptions>(configuration) and later have controllers receive IOptions<MyOptions> via DI.
  
  
• Third-Party Containers: ASP.NET Core’s default container is simple but sufficient for most needs. If you need more advanced features (like child containers), you can integrate other IoC containers (Autofac, Castle Windsor, etc.). However, many find the built-in container to be lightweight and fast enough, and you rarely need something heavier unless you have very specific requirements.
  
  

Frequently Asked Questions

• Can I inject into static methods or fields?
  No. The DI container only injects into classes it creates (via constructors or action parameters). Static methods/fields cannot receive injection directly. If needed, you’d manually retrieve a service via HttpContext.RequestServices.GetService, but this breaks DI principles.
  
  
• What if I forget to register a service?
  If you request a service that wasn’t registered, you’ll get a runtime error (usually an InvalidOperationException saying no service for type was registered). That’s a helpful reminder to register everything you need.
  
  
• Is it OK to inject IServiceProvider directly?
  Generally avoid injecting the service provider into your classes. It’s like using a Service Locator and defeats the purpose of DI by hiding dependencies. Stick to injecting the specific services you need.
  
  
• How do I manage lifetimes carefully?
  Be aware that scoped services should not be injected into singleton services, because a singleton lives longer than a scoped (request) lifetime. Doing so may capture a scoped object for longer than intended. ASP.NET Core will warn or even throw if it detects invalid usage (e.g., injecting a scoped into a singleton).
  
  

Conclusion

Dependency Injection in ASP.NET Core is a foundational pattern that simplifies application architecture. With DI, your classes declare their needs as interfaces, and the ASP.NET Core framework injects the concrete instances at runtime. This leads to code that is more modular, easier to maintain, and easier to test. As you build ASP.NET Core apps whether web APIs, MVC apps, Razor Pages, or background workers, you will rely on the built-in DI container to manage services.

Dependency Injection is a core pattern that can make your ASP.NET Core apps cleaner, scalable, and testable. When you embrace DI, you move toward clean architecture and decouple your codebase. ASP.NET Core has made DI so intuitive that once you get the hang of it, you’ll wonder how you ever coded without it. Whether you're building microservices, REST APIs, or large enterprise applications, mastering DI is a must-have skill in your .NET toolbox.

By decoupling dependencies, enforcing interface-driven design, and leveraging lifetimes, it enables scalable, testable, and maintainable applications. Embrace DI to transform tightly coupled code into modular, future-proof solutions. As you implement DI, prioritize:

• Interface segregation for flexibility.
• Lifetime awareness to prevent bugs.
• Constructor injection for clarity.

By mastering DI, you elevate your .NET applications from functional to exceptional.

In summary, Dependency Injection in ASP.NET Core provides a built-in IoC container that helps you wire up services cleanly. You register services in Program.cs, specify lifetimes (Transient, Scoped, Singleton), and then simply consume the services via constructor parameters. The framework takes care of creating and disposing of objects, following the rules you set up. This design results in loosely coupled components and adheres to best practices like the Dependency Inversion Principle. By understanding DI, service lifetimes, and the registration process, you can build flexible, testable ASP.NET Core applications with confidence.