📝 Lesson 5.2: Dependency Injection

The Coupling Problem

When a class creates its own dependencies with new, it becomes tightly coupled to those concrete types. Consider an order service that news-up its collaborators:

public class OrderService
{
    private readonly SmtpEmailSender _email = new SmtpEmailSender();   // hard-wired
    private readonly SqlOrderRepository _repo = new SqlOrderRepository();

    public void PlaceOrder(Order order)
    {
        _repo.Save(order);
        _email.Send(order.CustomerEmail, "Order confirmed");
    }
}

The class does two jobs: its real work and constructing its dependencies. Separating those is the heart of DI.

Dependency Inversion

The fix follows the Dependency Inversion Principle: depend on abstractions (interfaces, from the intro course), not concrete types. Define what you need as interfaces:

public interface IEmailSender { void Send(string to, string message); }
public interface IOrderRepository { void Save(Order order); }

"Inversion" refers to flipping who's in control: the class no longer decides which concrete types to use — the caller (or a container) does. The class just declares "I need an IEmailSender."

Constructor Injection

The dominant DI pattern is constructor injection: the class accepts its dependencies as constructor parameters and stores them. It never uses new for them:

public class OrderService
{
    private readonly IEmailSender _email;
    private readonly IOrderRepository _repo;

    // Dependencies are injected — the class depends only on abstractions
    public OrderService(IEmailSender email, IOrderRepository repo)
    {
        _email = email;
        _repo = repo;
    }

    public void PlaceOrder(Order order)
    {
        _repo.Save(order);
        _email.Send(order.CustomerEmail, "Order confirmed");
    }
}

Someone still has to supply the concrete types. In a tiny app you could do it by hand (new OrderService(new SmtpEmailSender(), new SqlOrderRepository())), but as the graph grows, wiring it manually gets unwieldy. That's the container's job.

The IoC Container

An Inversion of Control (IoC) container is a registry that knows how to build your objects and their dependencies. You register which implementation to use for each interface; then you resolve a type and the container constructs the whole graph. .NET's built-in container is Microsoft.Extensions.DependencyInjection.

dotnet add package Microsoft.Extensions.DependencyInjection

using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection();

// Register: "when someone needs IEmailSender, give them SmtpEmailSender"
services.AddSingleton<IEmailSender, SmtpEmailSender>();
services.AddScoped<IOrderRepository, SqlOrderRepository>();
services.AddTransient<OrderService>();

// Build the provider
using ServiceProvider provider = services.BuildServiceProvider();

// Resolve: the container constructs OrderService AND its dependencies
var orderService = provider.GetRequiredService<OrderService>();
orderService.PlaceOrder(order);

Service Lifetimes

When you register a service, you choose its lifetime — how long an instance lives and how often the container creates a new one:

DI and Testing

The biggest everyday payoff of DI is testability. Because OrderService depends on interfaces, a unit test (Intermediate) can inject fake implementations and verify behavior without a real database or email server:

// A hand-written fake (a "test double")
public class FakeEmailSender : IEmailSender
{
    public List<string> SentTo { get; } = new();
    public void Send(string to, string message) => SentTo.Add(to);
}

[Fact]
public void PlaceOrder_SendsConfirmationEmail()
{
    // Arrange — inject fakes, no real infrastructure
    var email = new FakeEmailSender();
    var repo = new FakeOrderRepository();
    var service = new OrderService(email, repo);

    // Act
    service.PlaceOrder(new Order { CustomerEmail = "a@b.com" });

    // Assert
    Assert.Contains("a@b.com", email.SentTo);
}

Exercise & Quiz

using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection();
// TODO: register IGreeter, ILogger, WelcomeService
using var provider = services.BuildServiceProvider();
// TODO: resolve WelcomeService and call Welcome("Ada")

interface IGreeter { string Greet(string name); }
interface ILogger { void Log(string msg); }

// TODO: ConsoleGreeter, ConsoleLogger, WelcomeService(IGreeter, ILogger)

using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection();
services.AddSingleton<IGreeter, ConsoleGreeter>();
services.AddSingleton<ILogger, ConsoleLogger>();
services.AddTransient<WelcomeService>();

using var provider = services.BuildServiceProvider();
var welcome = provider.GetRequiredService<WelcomeService>();
welcome.Welcome("Ada");

// Bonus: test with a fake logger (no container needed)
var fake = new FakeLogger();
var tested = new WelcomeService(new ConsoleGreeter(), fake);
tested.Welcome("Grace");
Console.WriteLine($"Logged {fake.Messages.Count} message(s).");

interface IGreeter { string Greet(string name); }
interface ILogger { void Log(string msg); }

class ConsoleGreeter : IGreeter
{
    public string Greet(string name) => $"Hello, {name}!";
}

class ConsoleLogger : ILogger
{
    public void Log(string msg) => Console.WriteLine($"[log] {msg}");
}

class WelcomeService
{
    private readonly IGreeter _greeter;
    private readonly ILogger _logger;

    public WelcomeService(IGreeter greeter, ILogger logger)
    {
        _greeter = greeter;
        _logger = logger;
    }

    public void Welcome(string name)
    {
        _logger.Log($"Welcoming {name}");
        Console.WriteLine(_greeter.Greet(name));
    }
}

class FakeLogger : ILogger
{
    public List<string> Messages { get; } = new();
    public void Log(string msg) => Messages.Add(msg);
}

Summary

📚 Additional Resources

• Dependency injection in .NET — Microsoft Docs
• DI guidelines & lifetimes
• DI in ASP.NET Core

🚀 What's Next?

You now have every advanced tool — and the architectural mindset to combine them. In the final lesson, Lesson 5.3: Capstone Project, you'll build a high-performance, concurrent, well-architected application that ties the whole course together.