Demystifying Dependency Injection in .NET: A Practical Guide

In modern software development, especially in the .NET ecosystem, Dependency Injection has become a cornerstone of building maintainable, testable, and scalable applications. Whether you’re working with ASP.NET Core, Blazor, or even desktop applications using .NET, understanding Dependency Injection is essential. In this blog post, we’ll explore what Dependency Injection is, why it matters, and how to use it effectively in .NET through the power of Dependency Injection.

What is Dependency Injection?

At its core, Dependency Injection is a design pattern used to implement Inversion of Control (IoC) between classes and their dependencies. Instead of a class creating its own dependencies, they are injected into it, usually through the constructor or a property. This approach is known as Dependency Injection, and it enables cleaner, more modular code.

Why Use Dependency Injection?

Without Dependency Injection, classes often create their own dependencies internally, leading to tightly coupled code:

publicclassOrderService

{

privatereadonly EmailService _emailService;

public OrderService()

{

_emailService = new EmailService(); // Hard dependency – no Dependency Injection

}

publicvoid PlaceOrder(Order order)

{

// Process order

_emailService.SendConfirmation(order);

}

}

This approach makes testing difficult and violates the Single Responsibility Principle. With Dependency Injection, we invert control:

publicclassOrderService

{

privatereadonly IEmailService _emailService;

public OrderService(IEmailService emailService) // Dependency Injection via constructor

{

_emailService = emailService;

}

publicvoid PlaceOrder(Order order)

{

// Process order

_emailService.SendConfirmation(order);

}

}

Now, OrderService doesn’t care how IEmailService is implemented, it just uses it. This is the essence of Dependency Injection: decoupling components for better flexibility. Dependency Injection makes the system more modular, easier to test, and simpler to extend.

Dependency Injection in .NET

Starting with .NET Core, Microsoft introduced a built-in Dependency Injection container that’s lightweight and sufficient for most applications. It’s automatically available in ASP.NET Core projects and can be used in any .NET application. This native Dependency Injection support is one of the reasons modern .NET apps are so clean and maintainable.

The Three Service Lifetimes in Dependency Injection

In .NET, when you register a service with the Dependency Injection container, you must specify its lifetime. There are three options:

1. Transient
   A new instance is created every time the service is requested—this is managed by the Dependency Injection system.csharp1services.AddTransient<IEmailService, EmailService>();Use for lightweight, stateless services where Dependency Injection ensures fresh instances.
2. Scoped
   One instance per request (in web apps) or per scope—handled by Dependency Injection.csharp1services.AddScoped<IOrderRepository, OrderRepository>();Ideal for database contexts where Dependency Injection manages context per operation.
3. Singleton
   A single instance is created and shared throughout the application’s lifetime via Dependency Injection.csharp1services.AddSingleton<ILogger, Logger>();Use for services that are thread-safe—Dependency Injection handles the lifecycle.

Caution: Be careful not to capture scoped or transient services in singletons, as this can lead to captive dependencies—a common pitfall when misusing Dependency Injection.

Setting Up Dependency Injection in ASP.NET Core

In an ASP.NET Core application, Dependency Injection is configured in the Program.cs file (or Startup.cs in older versions).

varbuilder = WebApplication.CreateBuilder(args);

// Register services using Dependency Injection

builder.Services.AddScoped<IOrderService, OrderService>();

builder.Services.AddTransient<IEmailService, EmailService>();

builder.Services.AddSingleton<ILogger, Logger>();

varapp = builder.Build();

// Use services in middleware, controllers, etc. via Dependency Injection

app.MapGet(“/orders”, (IOrderService orderService) =>

{

return orderService.GetOrders();

});

app.Run();

Notice how IOrderService is injected directly into the minimal API endpoint—this is Dependency Injection in action, reducing boilerplate and improving clarity.

Injecting Dependencies into Controllers with Dependency Injection

Controllers automatically receive their dependencies via constructor injection, a core feature of Dependency Injection:

[ApiController]

[Route(“[controller]”)]

publicclassOrdersController : ControllerBase

{

privatereadonly IOrderService _orderService;

public OrdersController(IOrderService orderService) // Dependency Injection at work

{

_orderService = orderService;

}

[HttpGet]

public IActionResult Get() => Ok(_orderService.GetOrders());

}

The framework handles the creation of OrdersController and injects the appropriate IOrderService implementation using Dependency Injection.

Advanced Scenarios Using Dependency Injection

1. Factory Pattern with Dependency Injection

Sometimes you need to create instances dynamically. You can inject a factory using Dependency Injection:

publicinterfaceIOrderProcessorFactory

{

IOrderProcessor CreateProcessor(OrderType type);

}

publicclassOrderProcessorFactory : IOrderProcessorFactory

{

privatereadonly IServiceProvider _serviceProvider;

public OrderProcessorFactory(IServiceProvider serviceProvider) // Dependency Injection

{

_serviceProvider = serviceProvider;

}

public IOrderProcessor CreateProcessor(OrderType type)

{

return type switch

{

OrderType.Standard => _serviceProvider.GetRequiredService<StandardOrderProcessor>(),

OrderType.Premium => _serviceProvider.GetRequiredService<PremiumOrderProcessor>(),

_ => thrownew ArgumentException(“Invalid order type”)

};

}

}

This pattern leverages Dependency Injection to resolve types dynamically.

2. Multiple Implementations with Dependency Injection

You can register multiple services for the same interface and resolve them as a collection, thanks to Dependency Injection:

services.AddTransient<INotificationService, EmailNotificationService>();

services.AddTransient<INotificationService, SmsNotificationService>();

// Later, inject all using Dependency Injection

publicclassNotificationService

{

privatereadonly IEnumerable<INotificationService> _services;

public NotificationService(IEnumerable<INotificationService> services) // Dependency Injection

{

_services = services;

}

publicvoid NotifyAll(string message)

{

foreach (varservicein _services)

{

service.Send(message);

}

}

}

This is a powerful use case of Dependency Injection enabling extensible architectures.

Best Practices for Dependency Injection

1. Use Interfaces
   Always depend on abstractions rather than concrete classes—this is fundamental to Dependency Injection.
2. Avoid Service Locator Pattern
   Don’t resolve services directly from IServiceProvider unless absolutely necessary. Let the Dependency Injection container manage dependencies.
3. Keep Constructors Simple
   Constructor injection should be straightforward—avoid complex logic during construction, which can interfere with Dependency Injection.
4. Testability
   Dependency Injection makes unit testing easier. You can inject mocks using frameworks like Moq:csharp12345678910111213[Fact]publicvoid PlaceOrder_Should_SendEmail(){// ArrangevarmockEmailService = new Mock<IEmailService>();varorderService = new OrderService(mockEmailService.Object); // Dependency Injection with mock// Act orderService.PlaceOrder(new Order());// Assert mockEmailService.Verify(s => s.SendConfirmation(It.IsAny<Order>()), Times.Once);}

This test relies on Dependency Injection to replace real dependencies with test doubles.

Conclusion

Dependency Injection is more than just a buzzword—it’s a powerful technique that promotes clean, testable, and maintainable code. The built-in Dependency Injection container in .NET makes it easy to adopt without requiring third-party libraries.

By embracing Dependency Injection, you’re not just following a pattern—you’re building applications that are easier to evolve, debug, and scale. Every time you use Dependency Injection, you’re investing in long-term code quality.

So the next time you’re tempted to new up a class inside another, pause and ask: “Could this be injected instead?” Your future self (and your team) will thank you, thanks to Dependency Injection.

Further Reading:

• Microsoft Docs: Dependency Injection in .NET
• Martin Fowler’s article on Inversion of Control

Happy coding!