Dependency Injection in ASP.NET Core

A class that creates its own dependencies decides for everyone: which database, which email sender, which clock. A class that receives them decides nothing, and the application decides once, in one place. That is dependency injection, and ASP.NET Core has a container for it built in and switched on.

In a web application there is an extra question that barely arises in a console program: how long should an instance live? A request is a natural boundary, and choosing the wrong side of that boundary is the most common way this goes wrong.

// Program.cs — builder phase
builder.Services.AddScoped<IEmployeeRepository, SqlEmployeeRepository>();
builder.Services.AddScoped<EmployeeService>();
builder.Services.AddSingleton<IDepartmentCodeCache, DepartmentCodeCache>();
builder.Services.AddTransient<IPayslipFormatter, PayslipFormatter>();

// EmployeeService.cs
public sealed class EmployeeService
{
    private readonly IEmployeeRepository _employees;
    private readonly ILogger<EmployeeService> _logger;

    public EmployeeService(IEmployeeRepository employees, ILogger<EmployeeService> logger)
    {
        _employees = employees;
        _logger = logger;
    }

    public async Task<Employee?> FindAsync(int id, CancellationToken ct)
    {
        var employee = await _employees.GetByIdAsync(id, ct);
        if (employee is null)
        {
            _logger.LogInformation("Employee {EmployeeId} was not found", id);
        }

        return employee;
    }
}

• Each Add call maps a service type to an implementation and states a lifetime. The interface is what consumers ask for, so the implementation can be replaced — in a test, or when the data store changes — without touching them.
• The repository and the service are both scoped. Everything in one request that needs the repository gets the same instance, which is what makes a shared transaction or a shared set of tracked entities possible.
• EmployeeService declares its needs in its constructor and nothing else. It never asks the container for anything, so reading the constructor tells you the complete list of what this class depends on.
• The logger is registered for you by the host. Any class can ask for ILogger of itself without registering anything.
• Nothing in this file constructs anything. The container creates instances when a request asks for them, working out the order from the constructors it can see.

public sealed class DepartmentCodeCache : IDepartmentCodeCache
{
    private readonly IServiceScopeFactory _scopeFactory;
    private Dictionary<string, string>? _codes;

    public DepartmentCodeCache(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    public async Task<IReadOnlyDictionary<string, string>> GetCodesAsync(CancellationToken ct)
    {
        if (_codes is not null)
        {
            return _codes;
        }

        using var scope = _scopeFactory.CreateScope();
        var departments = scope.ServiceProvider.GetRequiredService<IDepartmentRepository>();
        _codes = await departments.GetCodeMapAsync(ct);

        return _codes;
    }
}

• IServiceScopeFactory is itself a singleton, so a singleton may hold it safely.
• CreateScope produces a scope that this method owns, with the same rules a request scope has. The scoped repository is resolved inside it.
• The using declaration disposes the scope at the end of the method, and the repository with it. Nothing scoped is retained beyond the call.
• What the cache keeps is plain data, not another component's instance. Holding data in a singleton is fine; holding a shorter-lived service is not.
• One honest weakness: two requests arriving together can both find the field null and both load the map. The result is correct and the work is done twice. A production cache would guard the load, and pretending that detail away would teach the wrong thing.