Dependency Injection in Components

A component regularly needs something it should not build for itself: a way to load employees, somewhere to write a log entry, the current configuration. Dependency injection is the arrangement where the component states what it needs and the framework supplies an instance. The component never calls a constructor, so it never has to know how the thing it needs is put together.

You have already seen both halves of this without them being named. Program.cs registers services. Components ask for them. What this lesson adds is the asking, and one detail of the registration that behaves differently in Blazor than it does in an API — differently enough to cause real bugs in real applications.

That detail is worth stating up front. In ASP.NET Core, a scoped service lives for one HTTP request. In Blazor Server it lives for as long as the person keeps the tab open. Every instinct you have built about scoped services needs re-reading in that light.

@page "/employees"
@rendermode InteractiveServer
@inject IEmployeeDirectory Employees
@inject ILogger<EmployeeList> Logger

<h1>Employees</h1>

<ul>
    @foreach (var employee in employees)
    {
        <li @key="employee.Id">@employee.Name</li>
    }
</ul>

@code {
    [Inject]
    private NavigationManager Navigation { get; set; } = default!;

    private List<Employee> employees = [];

    protected override async Task OnInitializedAsync()
    {
        employees = await Employees.GetAllAsync();
        Logger.LogInformation("Loaded {Count} employees", employees.Count);
    }

    private void Open(int id) => Navigation.NavigateTo($"/employees/{id}");
}

• @inject declares a dependency in the markup. The first part is the type to resolve, the second is the name the rest of the file uses. The property is generated for you.
• [Inject] on a property in the @code block does the same job. Reach for it when the dependency belongs with the code rather than the markup, or when a base class needs it.
• = default!; tells the compiler the property will hold a value even though nothing in this file assigns one. The framework sets it after creating the component and before the first render.
• A component has no constructor injection. The framework creates the instance and then sets the injected properties, so a constructor runs before any dependency exists. That is why the load is in OnInitializedAsync and not in a constructor or a field initialiser.
• Employees with a capital E is the injected service; employees is the private field. C# is case-sensitive, so both names can coexist, and being deliberate about which is which keeps the markup readable.
• If IEmployeeDirectory is not registered, the failure happens when the component is created and the message names the missing type. That is the one error in this area that is straightforward to diagnose.

// Program.cs
builder.Services.AddDbContextFactory<PortalDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("Portal")));

builder.Services.AddScoped<IEmployeeDirectory, EmployeeDirectory>();
builder.Services.AddSingleton<IHolidayCalendar, HolidayCalendar>();
builder.Services.AddTransient<PayslipFormatter>();

// Services/EmployeeDirectory.cs
public sealed class EmployeeDirectory(IDbContextFactory<PortalDbContext> factory)
    : IEmployeeDirectory
{
    public async Task<List<Employee>> GetAllAsync(CancellationToken token = default)
    {
        await using var db = factory.CreateDbContext();

        return await db.Employees
            .AsNoTracking()
            .OrderBy(e => e.Name)
            .ToListAsync(token);
    }
}

• AddDbContextFactory registers a factory rather than a context. Nothing is created until a method asks, and the instance is disposed at the end of the using block.
• await using disposes the context asynchronously, which matters because closing a connection is I/O. DbContext supports both forms; prefer the async one in async code.
• AsNoTracking says this query is for display. The change tracker keeps no copies, so the query is cheaper and there is nothing left behind to go stale.
• EmployeeDirectory takes its dependency through a primary constructor. Services are ordinary classes with ordinary constructors — it is components, and only components, that cannot use constructor injection.
• IEmployeeDirectory is registered as scoped and that is fine, because it holds nothing between calls. Scoped becomes a problem when a service keeps state, not because of the word itself.
• IHolidayCalendar is a singleton because its data is the same for everyone and changes about once a year. PayslipFormatter is transient because it is cheap and holds nothing worth sharing.
• The CancellationToken has a default so callers who do not have one still compile, and it is passed to ToListAsync rather than accepted and dropped. The next lesson is about where that token comes from.