Dependency Injection in .NET Core: Complete Guide

 

Introduction to Dependency Injection in .NET Core

Dependency Injection (DI) is a design pattern that promotes loose coupling, testability, and maintainability in software applications. In .NET Core, DI is a first-class citizen, baked into the framework to make it easier to build scalable and testable applications. Whether you're developing a small API or a large enterprise application, mastering DI is essential for creating modular, maintainable code.

In this guide, we'll take you on a journey from the basics of DI to advanced scenarios, using real-world examples like building an e-commerce platform. We'll cover Inversion of Control (IoC) containers, service lifetimes, best practices, and more, with plenty of code examples to make the concepts crystal clear.

Why This Guide?

• Comprehensive: Covers beginner to advanced DI concepts.

• Practical: Uses a real-world e-commerce application scenario.

• SEO-Optimized: Designed to rank high on Google for terms like "Dependency Injection in .NET Core."

• Interactive: Includes exercises and code snippets you can try yourself.

---

Module 1: Understanding Dependency Injection and IoC

What is Dependency Injection?

Dependency Injection is a technique where an object receives its dependencies from an external source rather than creating them itself. This promotes loose coupling, making your code easier to test and maintain.

Real-World Analogy: Imagine a chef (your class) preparing a dish. Instead of growing vegetables and raising chickens (creating dependencies), the chef receives pre-prepared ingredients (dependencies) from a supplier (IoC container). This allows the chef to focus on cooking rather than managing ingredients.

What is Inversion of Control (IoC)?

IoC is the principle behind DI. It inverts the control of object creation and dependency management to a container, which handles the instantiation and injection of dependencies.

Why Use DI in .NET Core?

• Testability: Easily mock dependencies for unit testing.

• Flexibility: Swap implementations without changing the consuming class.

• Maintainability: Reduces tight coupling, making code easier to update.

• Scalability: Simplifies adding new features to large applications.

Pros and Cons of DI

Pros:

• Promotes loose coupling and modularity.

• Simplifies unit testing with mock objects.

• Enhances code reusability and maintainability.

Cons:

• Increases complexity for small projects.

• Can lead to over-engineering if misused.

• Learning curve for beginners.

Alternatives to DI

• Service Locator Pattern: Instead of injecting dependencies, a class requests them from a central registry. However, this can hide dependencies and make testing harder.

• Factory Pattern: A factory creates objects, but it may lead to tight coupling if not used carefully.

• Manual Dependency Management: Directly instantiating dependencies in code, which is simple but inflexible and hard to test.

Best Practice: Use DI for medium to large projects where testability and maintainability are priorities. For tiny scripts, manual dependency management may suffice.

---

Module 2: Setting Up DI in .NET Core

The Built-In IoC Container

.NET Core provides a lightweight, built-in IoC container through the Microsoft.Extensions.DependencyInjection package. While simple, it’s powerful enough for most applications. For advanced scenarios, you can use third-party containers like Autofac or Castle Windsor.

Setting Up a Basic .NET Core Application

Let’s create an e-commerce application to demonstrate DI. We’ll build a product catalog service that retrieves product details.

1. Create a New ASP.NET Core Project:

   dotnet new webapi -n ECommerceApp
   cd ECommerceApp

2. Add the DI Package (already included in ASP.NET Core): Ensure Microsoft.Extensions.DependencyInjection is referenced in your project.

Example: Basic DI Setup

Let’s define a ProductService and inject it into a controller.

// IProductService.cs
public interface IProductService
{
    List<string> GetProducts();
}

// ProductService.cs
public class ProductService : IProductService
{
    public List<string> GetProducts()
    {
        return new List<string> { "Laptop", "Phone", "Tablet" };
    }
}

// Startup.cs or Program.cs (for .NET 6+)
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container
builder.Services.AddControllers();
builder.Services.AddScoped<IProductService, ProductService>();

var app = builder.Build();
app.UseRouting();
app.UseEndpoints(endpoints => endpoints.MapControllers());
app.Run();

// ProductsController.cs
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductService _productService;

    public ProductsController(IProductService productService)
    {
        _productService = productService;
    }

    [HttpGet]
    public IActionResult Get()
    {
        var products = _productService.GetProducts();
        return Ok(products);
    }
}

Explanation:

• Interface: IProductService defines the contract.

• Implementation: ProductService provides the logic.

• Registration: AddScoped registers the service with the IoC container.

• Injection: The controller receives IProductService via constructor injection.

Try It Yourself: Run the application and navigate to /api/products. You should see a JSON response with the product list.

---

Module 3: Understanding Service Lifetimes

.NET Core supports three service lifetimes for registered services:

1. Transient: A new instance is created each time the service is requested.

2. Scoped: A single instance is created per scope (e.g., per HTTP request in ASP.NET Core).

3. Singleton: A single instance is created for the entire application lifetime.

Real-World Scenario: E-Commerce Order Processing

Imagine an e-commerce platform with:

• OrderService: Processes orders (Scoped, tied to a user session).

• NotificationService: Sends emails (Transient, a new instance per email).

• LoggingService: Logs application events (Singleton, shared across the app).

Example: Configuring Service Lifetimes

// IOrderService.cs
public interface IOrderService
{
    string ProcessOrder(int orderId);
}

// OrderService.cs
public class OrderService : IOrderService
{
    private readonly INotificationService _notificationService;

    public OrderService(INotificationService notificationService)
    {
        _notificationService = notificationService;
    }

    public string ProcessOrder(int orderId)
    {
        _notificationService.SendNotification($"Order {orderId} processed.");
        return $"Order {orderId} processed successfully.";
    }
}

// INotificationService.cs
public interface INotificationService
{
    void SendNotification(string message);
}

// NotificationService.cs
public class NotificationService : INotificationService
{
    public void SendNotification(string message)
    {
        Console.WriteLine($"Notification: {message}");
    }
}

// ILoggingService.cs
public interface ILoggingService
{
    void Log(string message);
}

// LoggingService.cs
public class LoggingService : ILoggingService
{
    public void Log(string message)
    {
        Console.WriteLine($"Log: {message}");
    }
}

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddTransient<INotificationService, NotificationService>();
builder.Services.AddScoped<IOrderService, OrderService>();
builder.Services.AddSingleton<ILoggingService, LoggingService>();

var app = builder.Build();
app.UseRouting();
app.UseEndpoints(endpoints => endpoints.MapControllers());
app.Run();

// OrdersController.cs
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    private readonly IOrderService _orderService;
    private readonly ILoggingService _loggingService;

    public OrdersController(IOrderService orderService, ILoggingService loggingService)
    {
        _orderService = orderService;
        _loggingService = loggingService;
    }

    [HttpPost("{orderId}")]
    public IActionResult ProcessOrder(int orderId)
    {
        _loggingService.Log($"Processing order {orderId}");
        var result = _orderService.ProcessOrder(orderId);
        return Ok(result);
    }
}

Explanation:

• Transient: NotificationService is created anew for each order, ensuring no state is shared.

• Scoped: OrderService is reused within the same HTTP request.

• Singleton: LoggingService is shared across all requests, maintaining a single instance.

Best Practices for Service Lifetimes

• Use Transient for stateless services or lightweight objects.

• Use Scoped for services tied to a user session or HTTP request (e.g., database contexts).

• Use Singleton for shared resources like loggers or configuration managers.

• Avoid Scoped/Singleton for stateful services to prevent unintended side effects.

Common Pitfall: Using a Transient service in a Singleton can lead to memory leaks if the Transient service holds resources.

---

Module 4: Advanced DI Scenarios

Scenario 1: Injecting Multiple Implementations

In an e-commerce platform, you might have multiple payment gateways (e.g., PayPal, Stripe). DI allows you to inject all implementations of an interface.

// IPaymentGateway.cs
public interface IPaymentGateway
{
    string ProcessPayment(decimal amount);
}

// PayPalGateway.cs
public class PayPalGateway : IPaymentGateway
{
    public string ProcessPayment(decimal amount)
    {
        return $"Processed ${amount} via PayPal";
    }
}

// StripeGateway.cs
public class StripeGateway : IPaymentGateway
{
    public string ProcessPayment(decimal amount)
    {
        return $"Processed ${amount} via Stripe";
    }
}

// Program.cs
builder.Services.AddSingleton<IPaymentGateway, PayPalGateway>();
builder.Services.AddSingleton<IPaymentGateway, StripeGateway>();

// PaymentController.cs
[ApiController]
[Route("api/[controller]")]
public class PaymentController : ControllerBase
{
    private readonly IEnumerable<IPaymentGateway> _paymentGateways;

    public PaymentController(IEnumerable<IPaymentGateway> paymentGateways)
    {
        _paymentGateways = paymentGateways;
    }

    [HttpPost("{gateway}/{amount}")]
    public IActionResult ProcessPayment(string gateway, decimal amount)
    {
        var selectedGateway = _paymentGateways.FirstOrDefault(g => g.GetType().Name.StartsWith(gateway, StringComparison.OrdinalIgnoreCase));
        if (selectedGateway == null)
            return BadRequest("Invalid gateway");
        var result = selectedGateway.ProcessPayment(amount);
        return Ok(result);
    }
}

Explanation: The controller receives all IPaymentGateway implementations and selects one based on the user’s input.

Scenario 2: Factory Pattern with DI

For dynamic dependency selection, use a factory.

// PaymentGatewayFactory.cs
public interface IPaymentGatewayFactory
{
    IPaymentGateway GetPaymentGateway(string gatewayName);
}

public class PaymentGatewayFactory : IPaymentGatewayFactory
{
    private readonly IServiceProvider _serviceProvider;

    public PaymentGatewayFactory(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public IPaymentGateway GetPaymentGateway(string gatewayName)
    {
        return gatewayName.ToLower() switch
        {
            "paypal" => _serviceProvider.GetService<PayPalGateway>(),
            "stripe" => _serviceProvider.GetService<StripeGateway>(),
            _ => throw new ArgumentException("Invalid gateway")
        };
    }
}

// Program.cs
builder.Services.AddSingleton<IPaymentGateway, PayPalGateway>();
builder.Services.AddSingleton<IPaymentGateway, StripeGateway>();
builder.Services.AddSingleton<IPaymentGatewayFactory, PaymentGatewayFactory>();

Best Practice: Use factories for runtime dependency selection to keep your code clean and maintainable.

---

Module 5: Unit Testing with DI

DI shines in unit testing by allowing you to mock dependencies. Let’s test the OrderService using Moq.

// Install Moq
// dotnet add package Moq

using Moq;
using Xunit;

public class OrderServiceTests
{
    [Fact]
    public void ProcessOrder_SendsNotification_ReturnsSuccessMessage()
    {
        // Arrange
        var mockNotificationService = new Mock<INotificationService>();
        var orderService = new OrderService(mockNotificationService.Object);
        int orderId = 1;

        // Act
        var result = orderService.ProcessOrder(orderId);

        // Assert
        mockNotificationService.Verify(n => n.SendNotification($"Order {orderId} processed."), Times.Once());
        Assert.Equal($"Order {orderId} processed successfully.", result);
    }
}

Explanation:

• Moq: Creates a mock INotificationService.

• Verify: Ensures the notification was sent.

• Assert: Checks the return value.

Best Practice: Always mock dependencies to isolate the unit under test. Avoid testing real implementations in unit tests.

---

Module 6: Using Third-Party IoC Containers

While .NET Core’s built-in container is sufficient for most cases, third-party containers like Autofac or Castle Windsor offer advanced features like:

• Property injection.

• Dynamic proxy generation.

• Module-based configuration.

Example: Using Autofac

1. Install Autofac:

   dotnet add package Autofac.Extensions.DependencyInjection

2. Configure Autofac:

// Program.cs
using Autofac;
using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;

var builder = WebApplication.CreateBuilder(args);

// Configure Autofac
builder.Host.UseServiceProviderFactory(new AutofacServiceProviderFactory());
builder.Host.ConfigureContainer<ContainerBuilder>(container =>
{
    container.RegisterType<ProductService>().As<IProductService>().InstancePerLifetimeScope();
});

builder.Services.AddControllers();

var app = builder.Build();
app.UseRouting();
app.UseEndpoints(endpoints => endpoints.MapControllers());
app.Run();

Pros of Autofac:

• Supports advanced features like property injection.

• Better for complex applications with many dependencies.

Cons:

• Adds complexity compared to the built-in container.

• Slightly slower startup time.

Best Practice: Use the built-in container for simple applications. Switch to Autofac or similar for complex scenarios requiring advanced DI features.

---

Module 7: Best Practices and Standards

Best Practices

1. Use Interfaces: Always define dependencies as interfaces to allow swapping implementations.

2. Avoid Service Locator: Prefer constructor injection over service locator to make dependencies explicit.

3. Validate Lifetimes: Ensure service lifetimes match their usage (e.g., don’t use Transient for database contexts).

4. Keep It Simple: Avoid overcomplicating small projects with DI.

5. Use Named Services Sparingly: Prefer factories or IEnumerable<T> for multiple implementations.

Standards

• Follow SOLID Principles, especially Dependency Inversion Principle (DIP).

• Use constructor injection as the default method for injecting dependencies.

• Register services in Program.cs or Startup.cs for consistency.

• Document dependencies clearly in your code and architecture.

Common Mistakes to Avoid

• Captive Dependencies: Using a shorter lifetime service in a longer lifetime service (e.g., Transient in Singleton).

• Over-Registration: Registering unnecessary services, slowing down startup.

• Ignoring Disposal: Ensure services implementing IDisposable are properly disposed by the container.

---

Module 8: Interactive Exercise

Challenge: Build a simple e-commerce API with:

• A ProductService to list products.

• A DiscountService to apply discounts (Transient).

• A CartService to manage user carts (Scoped).

• A LoggingService to log actions (Singleton).

Steps:

1. Define interfaces and implementations.

2. Register services with appropriate lifetimes.

3. Create a controller to list products with discounts and log actions.

4. Write unit tests using Moq to verify the behavior.

Solution (partial):

// ICartService.cs
public interface ICartService
{
    void AddToCart(string product);
    List<string> GetCart();
}

// CartService.cs
public class CartService : ICartService
{
    private readonly List<string> _cart = new List<string>();
    private readonly ILoggingService _loggingService;

    public CartService(ILoggingService loggingService)
    {
        _loggingService = loggingService;
    }

    public void AddToCart(string product)
    {
        _cart.Add(product);
        _loggingService.Log($"Added {product} to cart");
    }

    public List<string> GetCart()
    {
        return _cart;
    }
}

// Program.cs
builder.Services.AddScoped<ICartService, CartService>();

Try It Yourself: Complete the implementation and write tests. Share your solution on GitHub and tag it with #DotNetCoreDIChallenge!

---

Conclusion

Dependency Injection in .NET Core is a powerful tool for building testable, maintainable, and scalable applications. By understanding IoC containers, service lifetimes, and best practices, you can create robust systems like our e-commerce platform example. Whether you’re a beginner or an advanced developer, applying these concepts will elevate your .NET Core projects.

📘Free Job Preparation Zone 🎯 Visit Free Learning Zone