Understanding IoC Containers and the “D” in SOLID in .NET

Summary

In modern .NET development, writing maintainable, testable, and scalable code is essential. Two key concepts that help achieve this are:

• Inversion of Control (IoC) Containers
• Dependency Inversion Principle (D in SOLID)

Although often mentioned together, they are not the same thing. This article explains both concepts clearly and shows how they work together in .NET.

What is SOLID?

SOLID is a set of 5 design principles that improve software design:

• S: Single Responsibility Principle
• O: Open/Closed Principle
• L: Liskov Substitution Principle
• I: Interface Segregation Principle
• D: Dependency Inversion Principle

We’ll focus on D, because it directly relates to IoC.

What is the Dependency Inversion Principle (D)?

The Dependency Inversion Principle (DIP) states:

High-level modules should not depend on low-level modules. Both should depend on abstractions

In simple terms:

Instead of this:

public class OrderService
{
    private readonly EmailService _emailService = new EmailService();
}

We do this:

public class OrderService : IOrderService
{
    private readonly IEmailService _emailService;

    public OrderService(IEmailService emailService)
    {
        _emailService = emailService;
    }
}

Why this is better:

• Loosely coupled code
• Easier unit testing (mocking dependencies)
• Flexible implementations

What is Inversion of Control (IoC)?

Inversion of Control (IoC) is a design principle where:

The control of object creation is transferred from your code to an external system.

Without IoC:

var service = new OrderService(new EmailService());

With IoC:

You don’t create dependencies manually the framework does it for you.

What is an IoC Container?

An IoC Container (also called a Dependency Injection container) is a tool that:

• Creates objects
• Injects dependencies
• Manages object lifetimes

In .NET, the built-in container is:

Microsoft.Extensions.DependencyInjection

How IoC Works in .NET

Register services

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddScoped<IOrderService, OrderService>();
builder.Services.AddScoped<IEmailService, EmailService>();

Use constructor injection

public class OrderService : IOrderService
{
    private readonly IEmailService _emailService;

    public OrderService(IEmailService emailService)
    {
        _emailService = emailService;
    }
}

Inject via IOC the IOrderService Interface

using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/v1/[controller]")]
public class OrderController : ControllerBase
{
    private readonly IEmailService _emailService;

    // Dependency is injected automatically
    public OrderController(IEmailService emailService)
    {
        _emailService = emailService;
    }

    [HttpPost]
    public IActionResult CreateOrder()
    {
        // Use the dependency
        _emailService.Send("Order created!");

        return Ok("Order processed");
    }
}

What’s Happening Behind the Scenes?

When a request hits:

POST /api/order

.NET does this automatically:

1. Sees OrderController needs IEmailService
2. Looks in the container:

AddScoped<IEmailService, EmailService>()

1. Creates an instance of EmailService
2. Injects it into the controller constructor
3. Executes your action

You never manually create EmailServicethis is Inversion of Control in action.

Why This Demonstrates DIP

• Controller depends on **IEmailService (abstraction)**
• Not on **EmailService (concrete class)**
• Easily replaceable & testable

Unit Testing is now easy

var mockEmailService = new Mock<IEmailService>();

var controller = new OrderController(mockEmailService.Object);

Conclusion

In modern .NET applications, writing flexible and maintainable code is not just a best practice it’s a necessity. The Dependency Inversion Principle (D in SOLID) encourages developers to depend on abstractions rather than concrete implementations, reducing tight coupling and improving testability.

An IoC container brings this principle to life by taking over the responsibility of creating and managing dependencies. Instead of manually wiring objects together, you simply declare what your classes need, and the framework provides those dependencies automatically.

This combination leads to cleaner architecture, easier unit testing, and the ability to adapt your application as requirements evolve. Whether you’re swapping implementations, mocking dependencies, or scaling your system, IoC and DIP form the backbone of robust .NET design.

In short: Design for abstraction, and let the framework handle the rest.