ASP.NET Core Blazor with Entity Framework Core (EF Core)

This article explains how to use Entity Framework Core (EF Core) in server-side Blazor apps.

Server-side Blazor is a stateful app framework. The app maintains an ongoing connection to the server, and the user's state is held in the server's memory in a circuit. One example of user state is data held in dependency injection (DI) service instances that are scoped to the circuit. The unique application model that Blazor provides requires a special approach to use Entity Framework Core.

Secure authentication flow required for production apps

This article pertains to the use of a local database that doesn't require user authentication. Production apps should use the most secure authentication flow available. For more information on authentication for deployed test and production Blazor apps, see the articles in the Blazor Security and Identity node.

For Microsoft Azure services, we recommend using managed identities. Managed identities securely authenticate to Azure services without storing credentials in app code. For more information, see the following resources:

• What are managed identities for Azure resources? (Microsoft Entra documentation)
• Azure services documentation
  • Managed identities in Microsoft Entra for Azure SQL
  • How to use managed identities for App Service and Azure Functions

Database access

EF Core relies on a DbContext as the means to configure database access and act as a unit of work. EF Core provides the AddDbContext extension for ASP.NET Core apps that registers the context as a scoped service. In server-side Blazor apps, scoped service registrations can be problematic because the instance is shared across components within the user's circuit. DbContext isn't thread safe and isn't designed for concurrent use. The existing lifetimes are inappropriate for these reasons:

• Singleton shares state across all users of the app and leads to inappropriate concurrent use.
• Scoped (the default) poses a similar issue between components for the same user.
• Transient results in a new instance per request; but as components can be long-lived, this results in a longer-lived context than may be intended.

The following recommendations are designed to provide a consistent approach to using EF Core in server-side Blazor apps.

• Consider using one context per operation. The context is designed for fast, low overhead instantiation:

  using var context = new ProductsDatabaseContext();
  
  return await context.Products.ToListAsync();
  

• Use a flag to prevent multiple concurrent operations:

  if (Loading)
  {
      return;
  }
  
  try
  {
      Loading = true;
  
      ...
  }
  finally
  {
      Loading = false;
  }
  

  Place database operations after the Loading = true; line in the try block.

  Thread safety isn't a concern, so loading logic doesn't require locking database records. The loading logic is used to disable UI controls so that users don't inadvertently select buttons or update fields while data is fetched.

• If there's any chance that multiple threads may access the same code block, inject a factory and make a new instance per operation. Otherwise, injecting and using the context is usually sufficient.

• For longer-lived operations that take advantage of EF Core's change tracking or concurrency control, scope the context to the lifetime of the component.

New DbContext instances

The fastest way to create a new DbContext instance is by using new to create a new instance. However, there are scenarios that require resolving additional dependencies:

• Using DbContextOptions to configure the context.
• Using a connection string per DbContext, such as when you use ASP.NET Core's Identity model. For more information, see Multi-tenancy (EF Core documentation).

The recommended approach to create a new DbContext with dependencies is to use a factory. EF Core 5.0 or later provides a built-in factory for creating new contexts.

using System;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;

namespace BlazorServerDbContextExample.Data
{
    public class DbContextFactory<TContext> 
        : IDbContextFactory<TContext> where TContext : DbContext
    {
        private readonly IServiceProvider provider;

        public DbContextFactory(IServiceProvider provider)
        {
            this.provider = provider ?? throw new ArgumentNullException(
                $"{nameof(provider)}: You must configure an instance of " +
                "IServiceProvider");
        }

        public TContext CreateDbContext() => 
            ActivatorUtilities.CreateInstance<TContext>(provider);
    }
}

The following example configures SQLite and enables data logging in an app that manages contacts. The code uses an extension method (AddDbContextFactory) to configure the database factory for DI and provide default options:

builder.Services.AddDbContextFactory<ContactContext>(opt =>
    opt.UseSqlite($"Data Source={nameof(ContactContext.ContactsDb)}.db"));

services.AddDbContextFactory<ContactContext>(opt =>
    opt.UseSqlite($"Data Source={nameof(ContactContext.ContactsDb)}.db"));

The factory is injected into components to create new DbContext instances.

Scope a database context to a component method

The factory is injected into the component:

@inject IDbContextFactory<ContactContext> DbFactory

Create a DbContext for a method using the factory (DbFactory):

private async Task DeleteContactAsync()
{
    using var context = DbFactory.CreateDbContext();

    if (context.Contacts is not null)
    {
        var contact = await context.Contacts.FirstAsync(...);

        if (contact is not null)
        {
            context.Contacts?.Remove(contact);
            await context.SaveChangesAsync();
        }
    }
}

Scope a database context to the lifetime of the component

You may wish to create a DbContext that exists for the lifetime of a component. This allows you to use it as a unit of work and take advantage of built-in features, such as change tracking and concurrency resolution.

Implement IDisposable and inject the factory into the component:

@implements IDisposable
@inject IDbContextFactory<ContactContext> DbFactory

Establish a property for the DbContext:

private ContactContext? Context { get; set; }

OnInitializedAsync is overridden to create the DbContext:

protected override async Task OnInitializedAsync()
{
    Context = DbFactory.CreateDbContext();
}

The DbContext is disposed when the component is disposed:

public void Dispose() => Context?.Dispose();

Enable sensitive data logging

EnableSensitiveDataLogging includes application data in exception messages and framework logging. The logged data can include the values assigned to properties of entity instances and parameter values for commands sent to the database. Logging data with EnableSensitiveDataLogging is a security risk, as it may expose passwords and other Personally Identifiable Information (PII) when it logs SQL statements executed against the database.

We recommend only enabling EnableSensitiveDataLogging for development and testing:

#if DEBUG
    services.AddDbContextFactory<ContactContext>(opt =>
        opt.UseSqlite($"Data Source={nameof(ContactContext.ContactsDb)}.db")
        .EnableSensitiveDataLogging());
#else
    services.AddDbContextFactory<ContactContext>(opt =>
        opt.UseSqlite($"Data Source={nameof(ContactContext.ContactsDb)}.db"));
#endif

Additional resources

• EF Core documentation
• Blazor samples GitHub repository (dotnet/blazor-samples)
• Blazor Security and Identity node articles