Dependency Injection

By the end of this lesson you'll be able to decouple your classes by injecting their dependencies through constructors, wire a service graph by hand and with .NET's built-in container, choose the right service lifetime, and write code that's genuinely easy to test.

1. Constructor Injection — The Core Idea

When a class creates its own dependency with new, it is tightly coupled to that exact implementation — you can't swap it, and you can't test the class in isolation. Constructor injection fixes this: the class declares the interface it needs as a constructor parameter, and the caller passes in a concrete implementation. The class depends on the contract (the interface), never the concrete type. Read this worked example, run it, then you'll do the refactor yourself.

using System;

// === The PROBLEM: a class that builds its own dependency with 'new' ===
// EmailNotifier is hard-wired in. You cannot swap it or test around it.
class TightOrderService
{
    private readonly EmailNotifier _notifier = new EmailNotifier(); // hard dependency!

    public void Place(string item)
    {
        Console.WriteLine($"Order placed: {item}");
        _notifier.Notify($"We shipped your {item}");
    }
}

// === The FIX: depend on an INTERFACE, receive it through the const
...

Your turn. The Greeter below needs an IMessageService, but the constructor isn't finished. Add the parameter and store it, then wire it by hand in Main. Fill in the three ___ blanks, then run it.

using System;

// A tiny messaging contract.
interface IMessageService
{
    string Format(string text);
}

class PlainMessageService : IMessageService
{
    public string Format(string text) => text;
}

// 🎯 YOUR TURN — Greeter currently builds its OWN service with 'new'.
// Refactor it to receive an IMessageService through its constructor.
class Greeter
{
    private readonly IMessageService _messages;

    // 1) Add a constructor that takes an IMessageService and stores it.
    public Greete
...

2. Swapping Implementations — The Payoff

Here's why the effort is worth it. Because Greeter depends on the IMessageService interface and not a concrete class, you can hand it a completely different implementation without changing a single line of Greeter. That's loose coupling in action — and it's the same trick that lets you inject a fake service during testing. Swap the implementation in the two blanks below.

using System;

interface IMessageService
{
    string Format(string text);
}

class PlainMessageService : IMessageService
{
    public string Format(string text) => text;          // "Hello, Sam!"
}

// 🎯 YOUR TURN — a SECOND implementation already exists below.
// Because Greeter depends on the INTERFACE, you can swap it in without
// touching Greeter at all. That is the whole payoff of DI.
class ShoutingMessageService : IMessageService
{
    public string Format(string text) => text.ToUpper()
...

3. The IoC Container — Wiring Done For You

Wiring two classes by hand is easy. Wiring fifty, each depending on several others, is not — you'd be writing pages of new in the right order. An IoC container solves this: you register each interface against its implementation once with AddSingleton / AddScoped / AddTransient, call BuildServiceProvider(), then ask for a service with GetService<T>(). The container inspects each constructor and supplies the whole dependency graph automatically. .NET ships one built in — ServiceCollection from Microsoft.Extensions.DependencyInjection.

using System;
using Microsoft.Extensions.DependencyInjection;

// Wiring graphs by hand is fine for two classes — but a real app has
// dozens of services with nested dependencies. An IoC ("Inversion of
// Control") CONTAINER does the wiring for you: you register each type
// once, then ask the container for a service and it builds the whole graph.

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

...

Note: GetService<T>() returns null if a service wasn't registered; GetRequiredService<T>() throws a clear exception instead. In real apps, prefer GetRequiredService so a missing registration fails loudly.

4. Service Lifetimes — Singleton, Scoped, Transient

When you register a service you choose how long each instance lives. A Singleton is created once and shared for the entire app. A Scoped service is created once per scope — in a web app, that's typically one HTTP request. A Transient service is built fresh every single time it's resolved. Picking the wrong one causes subtle, hard-to-find bugs, so it's worth seeing the difference. Each service below stamps itself with a unique id so you can tell instances apart.

using System;
using Microsoft.Extensions.DependencyInjection;

// Each service stamps itself with a unique Id at creation time, so we can
// SEE whether the container handed us the same instance or a fresh one.
class SingletonService { public Guid Id { get; } = Guid.NewGuid(); }
class ScopedService    { public Guid Id { get; } = Guid.NewGuid(); }
class TransientService { public Guid Id { get; } = Guid.NewGuid(); }

class Program
{
    static void Main()
    {
        var services = new ServiceCo
...

// ❌ Captive dependency — a Scoped service trapped in a Singleton
services.AddSingleton<ICache, Cache>();      // lives forever
services.AddScoped<IDbContext, DbContext>(); // meant to be per-request
// Cache's constructor takes IDbContext -> that DbContext is now a singleton too!

// ✅ Fix: don't inject the scoped service directly. Inject a factory
//    (IServiceScopeFactory) and create a fresh scope when you need it.

5. Why DI Makes Code Testable

This is the payoff that wins teams over. Because a class receives its dependencies through its constructor, a unit test can pass in a fake — an in-memory stand-in you fully control — instead of the real database, payment gateway, or email server. No network, no slow setup, and you can inspect exactly what the class did. Without DI you'd be stuck with whatever the class new-ed internally.

using System;

// DI's biggest practical win: you can swap a real dependency for a FAKE
// one in tests — no database, no network, just a stand-in you control.

interface IPaymentGateway
{
    bool Charge(decimal amount);
}

// The REAL gateway would call an external API (slow, costs money).
class StripeGateway : IPaymentGateway
{
    public bool Charge(decimal amount)
    {
        Console.WriteLine($"  [Stripe] charging £{amount}");
        return true;
    }
}

// A FAKE for tests — records w
...

using System;

// 🎯 MINI-CHALLENGE: Wire an OrderService graph BY HAND (no container).
//
// You are given two contracts and one implementation of each.
// OrderService needs BOTH an IRepository and an INotifier.
//
// 1. In Main, create an InMemoryRepository (an IRepository).
// 2. Create a ConsoleNotifier (an INotifier).
// 3. Construct an OrderService, INJECTING both dependencies via its constructor.
// 4. Call orders.Place("Keyboard").
//
// ✅ Expected output:
//    Saved order: Keyboard
//
...