Using Entity Framework Core with Blazor

[danroth27]

We need to consider how EntityFramework Core should be used with Blazor:

• DbContexts are typically setup as scoped services in ASP.NET Core, which means they live for a single request. With server-side Blazor apps the scope is the lifetime of the connection. What impact does this have on EF Core?
• Blazor is a client-side UI framework. With other client-side UI frameworks, like WPF/WinForms, the guidance from the EF team is that the DbContext should be tied to the life of the current window. What's the equivalent concept in Blazor (client-side/server-side)?
• Review Blazor + EF Core guidance with the EF team

@divega @ajcvickers

[detachmode]

yes, had this problem already and was wondering the same. Current solution for me was to create a new DB Context with the using statement inside every DataAccess method.

[vertonghenb]

Current solution is to make it Transient for Server Side Blazor.

[divega]

Blazor is a client-side UI framework. With other client-side UI frameworks, like WPF/WinForms, the guidance from the EF team is that the DbContext should be tied to the life of the current window. What's the equivalent concept in Blazor (client-side/server-side)?

Agreed. My read is that the first thing we need is a pattern for creating DbContext instances in which the lifetime of the DbContext is decoupled from the request scope, but you still get all the DbContext configuration from DI.

(Note: I am not familiar with Blazor yet, but I am making a few assumptions, like that request scopes still exist, and that in the same application you can mix Blazor with regular "stateless Web" usages)

One thing that I believe @davidfowl mentioned to me is that we could register a DbContext factory service in DI to simplify creating DbContext instance in a more ad-hoc manner when a request scope cannot be relied upon to control its lifetime.

EDIT: Currently, you can do this by creating an instance with the new keyword, passing the DbContextOptions<TContext> resolved from DI to the constructor. But I believe there is value in a factory.

This would allow you to control the lifetime of each individual DbContext explicitly, associate it with other objects if that helps, etc. I assume it would also give you a bit more flexibility than just changing the lifetime on AddDbContext to Transient, especially if you have scenarios in which you need to create more than one instance of the same DbContext inside another object (e.g. multiple using inside a method).

[divega]

If we identify a pattern equivalent to associating the lifetime of the context with a "window" that works in 80% of Blazor scenarios and we find a way to automate it, we can do that too.

[divega]

BTW, I created dotnet/efcore#4441 more than three years ago to have a DbContextFactory<TContext> registered in DI, but we ended up deciding not to implement it because you can achieve the same by by creating the DbContext with the new keyword, passing the DbContextOptions<TContext> resolved from DI to the constructor.

I now believe again there is probably value in having the factory registered, but I am curious if anyone thinks the pattern above is sufficient.

[danroth27]

yes, had this problem already and was wondering the same. Current solution for me was to create a new DB Context with the using statement inside every DataAccess method.

@detachmode @vertonghenb Part of this discussion is to ensure we've identified all of the related issues with using EF Core with Blazor today. To help us out, could you please clarify exactly what issues you hit?

[detachmode]

@danroth27
When registering the DbContext in the DI Container with AddDbContext this instance will be used over the lifetime of the request, which in case of Server-Side means, as long as the user stays on the page without manually triggering a reload (which in a SPA can be a long time). A DbContext will keep its loaded data from the DB cached, so if a table got updated in the DB (outside the current instance of the Blazor App) this data will not be visible to the user of the SPA, until he manually reloads the page. EF encourages to use a short lifetime for DBContext instances, so the caching of the data won't have this negative effect of stale data.

I went with the using statement over the transient solution, so I could use my data access layer even in Singleton instances, which was a design choice.