Mastering Dependency Injection in .NET Core: A Practical Guide

Explore the principles and practical implementation of Dependency Injection in .NET Core applications, focusing on improved testability, maintainability, and modular design.

/ Article
Mastering Dependency Injection in .NET Core: A Practical Guide
Photo by Google DeepMind on Unsplash

Dependency Injection (DI) is a fundamental design pattern in modern software development, particularly within the .NET Core ecosystem. It is a technique for achieving Inversion of Control (IoC) between classes and their dependencies. Understanding and implementing DI correctly can significantly improve the testability, maintainability, and scalability of your applications. This guide provides a detailed, step-by-step explanation of DI in .NET Core, offering practical examples and best practices.

The problem Dependency Injection solves

Software applications are often composed of many classes that collaborate to perform tasks. When one class directly creates instances of other classes it needs, a tight coupling forms between them. This tight coupling presents several challenges:

  • Reduced Testability: Testing a class becomes difficult because its dependencies are hardcoded. You cannot easily substitute real dependencies with mock objects for isolated unit testing.
  • Limited Flexibility: Changing an implementation of a dependency requires modifying all classes that directly instantiate it. This makes refactoring and evolving the application more complex.
  • Increased Complexity: Managing the lifecycle of dependent objects, especially those with complex setup or teardown requirements, becomes the responsibility of every consuming class. This leads to duplicated code and potential errors.

Consider a simple OrderProcessor class that directly creates an instance of a Logger and a PaymentGateway:

public class OrderProcessor
{
    private Logger _logger;
    private PaymentGateway _paymentGateway;

    public OrderProcessor()
    {
        _logger = new Logger(); // Tightly coupled
        _paymentGateway = new PaymentGateway(); // Tightly coupled
    }

    public void ProcessOrder(decimal amount)
    {
        _logger.LogInfo("Processing order...");
        _paymentGateway.Charge(amount);
        _logger.LogInfo("Order processed.");
    }
}

public class Logger
{
    public void LogInfo(string message)
    {
        Console.WriteLine($"INFO: {message}");
    }
}

public class PaymentGateway
{
    public void Charge(decimal amount)
    {
        Console.WriteLine($"Charging {amount} via PaymentGateway.");
    }
}

In this example, OrderProcessor is directly responsible for creating Logger and PaymentGateway. If you want to use a different logging mechanism or a different payment provider, you must change the OrderProcessor class itself. This is where Dependency Injection offers a solution.

Software Architecture Diagram
Photo by Google DeepMind on Unsplash

Core concepts of Dependency Injection

Dependency Injection is a design pattern that implements Inversion of Control (IoC). It allows you to inject the concrete implementation of a low-level component into a high-level component.

Inversion of Control (IoC)

Inversion of Control means that a class does not control the creation of its dependencies. Instead, an external entity provides those dependencies. This principle is often summarized as “Don’t call us; we’ll call you.” Classes declare their dependencies, typically through interfaces or abstract base classes, and rely on the IoC container to provide the necessary implementations.

Dependencies

A dependency is an object that another object needs to function. For example, OrderProcessor depends on ILogger and IPaymentGateway.

IoC Container (DI Container)

An IoC Container, also known as a Dependency Injection Container, is a framework that automates the process of Dependency Injection. It manages the creation and lifecycle of objects and ensures that dependencies are correctly resolved and provided when needed. In .NET Core, the built-in IoC Container implements the IServiceProvider interface.

The IoC Container performs three main tasks:

  • Registration: It needs to know which type of object to create for a specific dependency. You map an interface to a concrete class.
  • Resolution: It resolves a dependency by creating an object and injecting it into the requesting class. This eliminates the need for manual object instantiation.
  • Disposition: It manages the lifetime of registered services, ensuring they are disposed of appropriately.

Implementing Dependency Injection in .NET Core

.NET Core has a built-in DI container that simplifies dependency management. You register your application’s services (dependencies) with the container, and then the container provides instances of these services to classes that declare them as dependencies.

Setting up a .NET Core project

For this tutorial, you can create a new .NET Core console application or use an existing ASP.NET Core web application. The principles remain the same.

dotnet new console -n DiExample
cd DiExample

Next, define interfaces for your dependencies. This promotes loose coupling, as your OrderProcessor will depend on abstractions, not concrete implementations.

// Interfaces
public interface ILogger
{
    void LogInfo(string message);
}

public interface IPaymentGateway
{
    void Charge(decimal amount);
}

// Concrete Implementations
public class ConsoleLogger : ILogger
{
    public void LogInfo(string message)
    {
        Console.WriteLine($"ConsoleLogger INFO: {message}");
    }
}

public class StripePaymentGateway : IPaymentGateway
{
    public void Charge(decimal amount)
    {
        Console.WriteLine($"StripePaymentGateway charging {amount}.");
    }
}

// The consuming class, now dependent on interfaces
public class OrderProcessor
{
    private readonly ILogger _logger;
    private readonly IPaymentGateway _paymentGateway;

    public OrderProcessor(ILogger logger, IPaymentGateway paymentGateway)
    {
        _logger = logger;
        _paymentGateway = paymentGateway;
    }

    public void ProcessOrder(decimal amount)
    {
        _logger.LogInfo("Processing order with DI...");
        _paymentGateway.Charge(amount);
        _logger.LogInfo("Order processed with DI.");
    }
}

Registering services in Program.cs

In modern .NET Core applications, you register services in the Program.cs file. This is where you configure the DI container.

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using DiExample; // Assuming your classes are in the DiExample namespace

class Program
{
    static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureServices((hostContext, services) =>
            {
                // Register services
                services.AddSingleton<ILogger, ConsoleLogger>();
                services.AddTransient<IPaymentGateway, StripePaymentGateway>();
                services.AddTransient<OrderProcessor>(); // Register the consuming class itself
            })
            .ConfigureLogging(logging =>
            {
                // Optional: Configure logging if needed
            })
            .UseConsoleLifetime(); // Ensures the console app runs until explicitly stopped
}

In this setup, CreateHostBuilder configures the host and its services. Inside ConfigureServices, we use extension methods like AddSingleton and AddTransient to register our interfaces with their concrete implementations. We also register OrderProcessor itself, so the container can resolve its dependencies.

Constructor Injection

Constructor injection is the preferred method for resolving dependencies. The DI container inspects the constructor of a class, identifies the required dependencies, and automatically provides instances of those dependencies.

Our OrderProcessor class demonstrates constructor injection:

public class OrderProcessor
{
    private readonly ILogger _logger;
    private readonly IPaymentGateway _paymentGateway;

    public OrderProcessor(ILogger logger, IPaymentGateway paymentGateway) // Dependencies injected via constructor
    {
        _logger = logger;
        _paymentGateway = paymentGateway;
    }

    // ... methods
}

When the DI container creates an instance of OrderProcessor, it looks at its constructor, sees ILogger and IPaymentGateway, and then provides instances of ConsoleLogger and StripePaymentGateway (based on our registrations).

Code Editor Screen
Photo by Mohammad Rahmani on Unsplash

Property and Method Injection (briefly)

While constructor injection is generally recommended, other forms exist:

  • Property Injection: Dependencies are injected through public properties. This is less common because it can lead to optional dependencies, making the class’s requirements less explicit.
  • Method Injection: Dependencies are passed as parameters to a specific method. This is useful when a dependency is only needed for a single method call.

For most scenarios, constructor injection provides the clearest and most robust way to manage dependencies.

Service lifetimes explained with examples

When registering services, you specify their lifetime. This determines how long a service instance lives and how it is shared across different components and requests. .NET Core offers three primary service lifetimes:

AddSingleton

A service registered with a singleton lifetime is created only once during the application’s lifetime. The same instance is then shared across all subsequent requests for that service.

  • When to use: For stateless services, configuration objects, or services that are expensive to create and can be safely shared across the entire application. Examples include logging services or caching services.
  • Example: 
    services.AddSingleton<ILogger, ConsoleLogger>();
    Every time ILogger is requested, the same ConsoleLogger instance will be provided.

AddScoped

A service with a scoped lifetime is created once per client request (or scope). In ASP.NET Core web applications, a scope typically corresponds to an HTTP request. This means that within a single HTTP request, all components requesting a scoped service will receive the same instance. However, a new instance is created for each new HTTP request.

  • When to use: For services that maintain state within a request, such as database contexts (e.g., Entity Framework DbContext is typically scoped by default) or services that need to track operations specific to a single user interaction.
  • Example: 
    services.AddScoped<IPaymentGateway, StripePaymentGateway>();
    If IPaymentGateway is requested multiple times within the same HTTP request, the same StripePaymentGateway instance will be used. A new instance will be created for the next HTTP request.

AddTransient

A service with a transient lifetime is created every time it is requested from the service container. This means that if a class requests a transient service multiple times, it will receive a new instance each time.

  • When to use: For lightweight, stateless services that do not hold conversational state, or when you need a fresh instance of a service every time it is used.
  • Example: 
    services.AddTransient<OrderProcessor>();
    Every time OrderProcessor is requested, a brand new instance of OrderProcessor is created.

Choosing the correct lifetime is important to avoid issues like memory leaks or incorrect state management.

Practical application and benefits

Implementing Dependency Injection offers significant advantages:

  • Improved Testability: DI makes unit testing much easier. You can inject mock or stub implementations of dependencies, allowing you to test a class in isolation without relying on its real dependencies. This is a cornerstone of robust software development.
  • Enhanced Maintainability and Modularity: By depending on abstractions (interfaces) rather than concrete classes, your code becomes more modular. You can change the implementation of a dependency without affecting the consuming classes, as long as the interface contract remains the same.
  • Easier Code Reusability: Services designed with DI in mind are often more generic and can be reused in different parts of an application or even across different applications.
  • Reduced Boilerplate: The DI container handles the instantiation and resolution of dependencies, reducing the amount of manual object creation code you need to write.
  • Promotes SOLID Principles: DI strongly aligns with the Dependency Inversion Principle (DIP), which states that high-level modules should not depend on low-level modules, but both should depend on abstractions.

Common pitfalls and best practices

While powerful, DI can be misused. Adhering to best practices ensures you leverage its benefits effectively.

  • Avoid over-injecting dependencies: A class with too many injected dependencies might indicate it has too many responsibilities. This suggests a violation of the Single Responsibility Principle. Aim for small, focused interfaces and classes.
  • Mismanaging lifetimes: Incorrectly assigning service lifetimes can lead to bugs. For example, injecting a scoped service into a singleton service can cause the scoped service to behave like a singleton, leading to incorrect state across requests. In development, .NET Core can throw an exception if it detects such a scenario.
  • Avoid the “Service Locator” anti-pattern: Do not retrieve dependencies using IServiceProvider manually within your application code when you can use DI instead. This pattern hides dependencies and makes testing harder, effectively undermining the benefits of DI.
  • Inject interfaces, not implementations: Always depend on abstractions (interfaces) rather than concrete classes. This is fundamental to loose coupling.
  • Keep DI factories fast and synchronous: Avoid complex or asynchronous logic within your service registration factories.
  • Design services for DI: Avoid stateful, static classes and members. Design services to be small, well-factored, and easily testable.

Conclusion

Dependency Injection is a cornerstone of building robust, maintainable, and testable applications in .NET Core. By embracing IoC and leveraging the built-in DI container, developers can decouple components, simplify testing, and create more flexible and scalable software systems. Understanding service lifetimes and adhering to best practices are essential for harnessing the full power of this fundamental design pattern.

Works Cited