Dependency Injection

Start with the plain idea, because the name makes it sound larger than it is. A class states what it needs in its constructor, and something else supplies it. That is all dependency injection means.

The alternative is a class that constructs its own collaborators. That seems simpler, and it costs you three things. The class decides how its collaborators are built, so changing that decision means editing the class. Nothing can be substituted, so a test needs a real database and a real mail server. And the same collaborator gets constructed repeatedly in different places, each with its own idea of the correct settings.

The container is the piece that makes handing things over practical. You register what implements what, once, and it constructs objects on demand — including the objects those objects need, all the way down. You never write the wiring.

// Before: this class decides everything, and nothing here can be substituted
public sealed class EmployeeService
{
    public async Task PromoteAsync(int employeeId, string newTitle)
    {
        var store = new PostgresEmployeeStore("Host=prod-db;Database=employees;...");
        var email = new SmtpNotificationSender("smtp.internal", 25);

        Employee employee = await store.GetAsync(employeeId);
        await store.UpdateTitleAsync(employeeId, newTitle);
        await email.SendAsync(employee.Email, "Your new job title");
    }
}

// After: the class states its needs and is handed them
public sealed class EmployeeService(
    IEmployeeStore store,
    INotificationSender notifications)
{
    public async Task PromoteAsync(int employeeId, string newTitle)
    {
        Employee employee = await store.GetAsync(employeeId);
        await store.UpdateTitleAsync(employeeId, newTitle);
        await notifications.SendAsync(employee.Email, "Your new job title");
    }
}

• The first version has a connection string and an SMTP host compiled into a business method. Every environment needs a different one, so this class cannot run anywhere but the machine it was written for.
• It also cannot be tested without sending an email. There is no seam: the method builds its collaborators itself, so no test can intercept them.
• The second version names what it needs as interfaces. It has no opinion about which database or which mail server, and a test constructs it with two in-memory doubles and no infrastructure at all.
• The parameters on the class declaration are a primary constructor, and the parameters are usable directly in the methods below. The older form with explicit fields assigned in a constructor body behaves identically.
• Note what has not happened: the class does not ask a container for anything. It does not reference the container at all. Being handed your dependencies and asking a global object for them are different designs, and only the first is testable.

var builder = Host.CreateApplicationBuilder(args);

// One instance for the whole process
builder.Services.AddSingleton<IClock, SystemClock>();

// One instance per unit of work — a web request, or a scope you create
builder.Services.AddScoped<IEmployeeStore, PostgresEmployeeStore>();
builder.Services.AddScoped<EmployeeService>();

// A new instance every time one is asked for
builder.Services.AddTransient<EmployeeValidator>();

// A factory, for when construction needs more than the container can work out
builder.Services.AddSingleton<INotificationSender>(provider =>
{
    var options = provider.GetRequiredService<IOptions<SmtpOptions>>().Value;
    return new SmtpNotificationSender(options.Host, options.Port);
});

using IHost host = builder.Build();

• Each Add call records a mapping from a requested type to a way of creating it. Nothing is constructed here — registration is a list, not a set of objects.
• When something asks for EmployeeService, the container looks at its constructor, resolves an IEmployeeStore and an INotificationSender, resolves anything those need, and then constructs the service. That recursion is the part you would otherwise write by hand.
• AddScoped<EmployeeService>() with no interface is a legitimate registration. You are not required to invent an interface for every class — register the concrete type when nothing needs to substitute it.
• The factory overload handles construction the container cannot infer, such as a constructor taking a host name and a port. Prefer options binding over reading configuration inside a factory, so the values are still validated at start-up.
• The container disposes what it creates: scoped and transient IDisposable instances when their scope ends, singletons when the host shuts down. Objects you construct yourself with new and hand over are not the container's to dispose.

public sealed class EmployeeSyncWorker(
    IServiceScopeFactory scopeFactory,
    IOptionsMonitor<EmployeeOptions> options,
    ILogger<EmployeeSyncWorker> logger) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            int intervalMinutes = options.CurrentValue.SyncIntervalMinutes;

            using (IServiceScope scope = scopeFactory.CreateScope())
            {
                var service = scope.ServiceProvider.GetRequiredService<EmployeeService>();
                int updated = await service.SyncFromPayrollAsync(stoppingToken);
                logger.LogInformation("Synced {UpdatedCount} employees", updated);
            }

            await Task.Delay(TimeSpan.FromMinutes(intervalMinutes), stoppingToken);
        }
    }
}

• The worker takes IServiceScopeFactory rather than EmployeeService. Its own lifetime is the whole process, so anything scoped it held in a constructor would be captive for hours.
• CreateScope opens the boundary. Everything resolved inside it — the service, its store, the database session underneath — belongs to this one cycle.
• The using block closes and disposes the scope at the end of each cycle. That is what returns the session to the pool and releases the entities it tracked. Without it you have rebuilt the captive dependency by hand.
• IOptionsMonitor rather than IOptionsSnapshot, for the same reason: the worker is a singleton, and a snapshot is scoped.
• The cancellation token is passed to both the work and the delay, so a stop signal interrupts the wait instead of leaving the host to time out. The lifecycle lesson covers what happens on that signal.