Dependency Injection Concepts

Start with the idea, because the term gets in the way. A class needs things to do its job: somewhere to save an order, something to send an email, a clock to read the time. It can either create those things itself, or be handed them.

Being handed them is the whole idea. The class states what it needs in its constructor and someone else decides what to supply. That is all dependency injection means.

The word injection describes the handing over. The word dependency describes the thing being handed. Both are more intimidating than the concept, which is closer to a recipe listing its ingredients than going shopping.

// Version 1: constructs what it needs. Works, and cannot be tested.
public class OrderServiceA
{
    public string Confirm(int orderId)
    {
        SqlOrderStore store = new("Server=live-db;Database=Sales;...");
        SmtpEmailSender email = new("smtp.supplier.example", 587);

        Order? order = store.Find(orderId);

        if (order is null)
        {
            return "Not found.";
        }

        order.ConfirmedAt = DateTime.Now;
        store.Save(order);
        email.SendConfirmation(order);

        return "Confirmed.";
    }
}

// Version 2: states what it needs and is given it.
public class OrderServiceB
{
    private readonly IOrderStore _store;
    private readonly IEmailSender _email;
    private readonly TimeProvider _time;

    public OrderServiceB(IOrderStore store, IEmailSender email, TimeProvider time)
    {
        _store = store;
        _email = email;
        _time = time;
    }

    public string Confirm(int orderId)
    {
        Order? order = _store.Find(orderId);

        if (order is null)
        {
            return "Not found.";
        }

        order.ConfirmedAt = _time.GetUtcNow().UtcDateTime;
        _store.Save(order);
        _email.SendConfirmation(order);

        return "Confirmed.";
    }
}

• Version 1 names three concrete things it cannot do without: a SQL connection string, an SMTP server, and the machine clock. Calling Confirm on it requires a reachable database and mail server. There is no way to test it without them, because there is no seam — no point at which you could put something else in.
• It has a second problem that shows up later. The connection string is buried inside a method, so configuration is now spread across every class that happens to need data.
• Version 2 names three abstractions in its constructor and stores them in readonly fields. The class no longer knows or cares whether the store talks to SQL Server, an in-memory dictionary, or a test double that records what it was asked to save.
• The interfaces are what create the seam. Depending on IOrderStore rather than SqlOrderStore is the part that makes substitution possible; the constructor parameter is just how the substitute arrives.
• The clock is included deliberately, because it is the dependency people forget. DateTime.Now is a hidden dependency on the machine, and it makes "confirmed yesterday" impossible to test. TimeProvider is the built-in abstraction for this, and it comes with a fake for tests.
• Nothing about version 2 requires a framework or a container. It is a constructor. You could construct it by hand in three lines, and in a test that is exactly what you do.

var builder = WebApplication.CreateBuilder(args);

// "When something asks for IOrderStore, give it SqlOrderStore."
builder.Services.AddScoped<IOrderStore, SqlOrderStore>();
builder.Services.AddScoped<OrderServiceB>();

// Shared for the whole application. Must be thread-safe.
builder.Services.AddSingleton<IPriceCache, InMemoryPriceCache>();
builder.Services.AddSingleton(TimeProvider.System);

// Cheap and stateless, so a fresh one each time costs nothing.
builder.Services.AddTransient<IEmailSender, SmtpEmailSender>();

var app = builder.Build();

app.MapPost("/orders/{orderId:int}/confirm",
    (int orderId, OrderServiceB service) => service.Confirm(orderId));

app.Run();

• Each registration is a rule: when a constructor asks for this type, provide that implementation. Nothing is created at this point.
• OrderServiceB is registered without an interface, which is fine. Registering a concrete class is common for application services that nothing needs to substitute.
• When a request arrives, the container reads OrderServiceB's constructor, sees it needs IOrderStore, IEmailSender and TimeProvider, resolves each one according to its lifetime, and constructs the service. This discovery is reflection, which is the previous lesson's subject appearing in something you use daily.
• The endpoint's second parameter is the service. ASP.NET Core recognises that it is not part of the route and resolves it from the container, so nothing in the handler constructs anything.
• AddSingleton(TimeProvider.System) registers an instance you already have rather than a type to construct. In a test you would register a fake time provider here instead, and every service that reads the clock would see the controlled time.
• Compare this to version 1. The connection string, the SMTP host and the choice of implementation are all decided here, in one file, next to each other — and changing any of them touches no service.