Dependency injection

Let classes receive their dependencies instead of creating them — for flexible, testable code.

The problem: classes that build their own world

public class OrderService
{
    private readonly SqlOrderRepository repository = new SqlOrderRepository("Server=prod;...");
    private readonly SmtpEmailSender email = new SmtpEmailSender("smtp.example.com");
 
    public void Place(Order order)
    {
        repository.Save(order);
        email.Send(order.CustomerEmail, $"Order {order.Id} confirmed");
    }
}

This works, but:

You can't test OrderService without a real database and mail server.
You can't swap SMTP for SendGrid without editing OrderService.
Configuration (connection strings) is buried inside the class.

The fix: ask for dependencies

Dependency injection (DI) means a class receives what it needs — usually through its constructor — instead of creating it:

public class OrderService(IOrderRepository repository, IEmailSender email)
{
    public void Place(Order order)
    {
        repository.Save(order);
        email.Send(order.CustomerEmail, $"Order {order.Id} confirmed");
    }
}

OrderService now depends only on interfaces. Production passes the real implementations; tests pass fakes. This is the dependency inversion principle — depend on abstractions, not concrete details (Track 12).

The container wires it up

Creating object graphs by hand gets tedious (new OrderService(new SqlOrderRepository(new DbContext(...)), new SmtpEmailSender(...))). A DI container does it for you. In ASP.NET Core, you register services at startup:

var builder = WebApplication.CreateBuilder(args);
 
builder.Services.AddScoped<IOrderRepository, SqlOrderRepository>();
builder.Services.AddSingleton<IEmailSender, SmtpEmailSender>();
builder.Services.AddScoped<OrderService>();
builder.Services.AddDbContext<ShopDb>(o => o.UseSqlServer(connectionString));   // registered as scoped

…and the framework resolves them: when an endpoint or controller needs an OrderService, the container sees its constructor wants an IOrderRepository and an IEmailSender, creates those (and their dependencies), and passes them in.

app.MapPost("/orders", (Order order, OrderService orders) =>   // injected automatically
{
    orders.Place(order);
    return Results.Created($"/orders/{order.Id}", order);
});

Lifetimes

Lifetime	Instances	Typical use
Singleton	One for the whole app	Stateless, thread-safe services; caches; `HttpClient` factories; configuration
Scoped	One per scope — in ASP.NET Core, per HTTP request	`DbContext`, unit-of-work, per-request user context
Transient	A new one every time it's resolved	Lightweight, stateless helpers

The container also disposes the IDisposable services it created, at the end of their lifetime.

Captive dependencies

A service must not depend on something with a shorter lifetime. A singleton that receives a scoped DbContext keeps that one context alive for the app's whole life — shared by every request and thread. ASP.NET Core's scope validation throws in Development to catch this. If a singleton truly needs scoped services, inject IServiceScopeFactory and create a scope when needed.

How a container works

There's no magic — at heart, a container is a dictionary from types to factory functions. Here's a toy one:

Program.csCtrl + Enter to run

Loading editor…

C# runtime not loaded

Real containers add lifetimes, disposal, open generics and constructor discovery via reflection — but the idea is the same.

Good DI habits

Prefer constructor injection; avoid calling serviceProvider.GetService<T>() all over the code (the service locator anti-pattern).
Keep constructors simple — just store dependencies.
Many constructor parameters (say, more than 5) suggest a class doing too much.
Wrap time, randomness, file system and network behind interfaces (TimeProvider is built in since .NET 8) so they can be faked in tests.

Key takeaways

DI: classes receive their dependencies (usually interfaces) instead of creating them.
Register services in builder.Services with a lifetime; the container resolves whole object graphs.
Singleton = one per app, scoped = one per request, transient = new each time.
Never let a long-lived service capture a shorter-lived one.

You will learn