Blazor server - how long is a transient service lifetime

From reading ASP.NET Core Razor component lifecycle I think that means a transient service, which has a lifetime of per request, then can be used for instances that are not thread safe (assuming I don't create background threads in my processing).

Yes there's several steps and it's possible to write code in OnInitialized() say that takes a couple of seconds. But fundamentally all the code is going to execute and render the page. And then done, the request is complete, and that transient instance is gone - forever.

So in terms of a DbContext, again assuming I'm not creating any background threads, while it's not safe to inject it as a singleton or scoped service, transient should be safe. Or am I missing something?

And if that is true, is there a way to tell AddDbContextFactory() to provide a DbContext as a transient service? Looking at the relevant classes I did not see any way of setting the generated DbContext lifetimes. And declaring it as [Inject] in a razor file connotates scope or singleton lifetime as it's there for the life of the component, not per request handled by the component.

Update:

I think I wrote the above wrong (or inartfully). My concern is the use of:

[Inject] private UserDbContext UserDbContext { get; set; } = default!;

This is created, as I understand it, by AddDbContextFactory. And I believe this is giving me a DbContext with a scope lifetime. And I'm concerned that this scope lifetime is problematic.

But I see that [Inject] in pretty much every demo.

Re the Update

> And I'm concerned that this scope lifetime is problematic.

It certainly is. That is the whole reason for adding and using the Factory. So you should not Inject a DbContext. The fact that AddDbContextFactory() registers both the factory and the (Scoped) context is misleading. You still have no Scopes to use the context with injection.

It has limited usefulness, there might be a case (for instance DataSeeding on startup) where you first create a Scope (manually) and then use the DbContext with injection.

> But I see that [Inject] in pretty much every demo.

Could you link to a few? It can be acceptable to keep a DbContext for the duration of a Page, but then you need a Dispose() on that Page. This is where OwningComponentBase was invented for.

Leaving it to the GC works too, the context is smart about managing its Connection. But still, that is very sloppy.

> is there a way to tell AddDbContextFactory() to provide a DbContext as a transient service?

No, a DbContext is IDisposable so you shouldn't want that.

The DbContextFactory itself is Transient, you use it to create a DbContext that is scoped to each method with a using clause: using var db = Factory.Create();. So the DbContext is resource-managed and thread-safe.

> that means a transient service, which has a lifetime of per request, then can be used for instances that are not thread safe

Transient objects are not tied to the request, they live as long as your code holds a reference to them.

It can be used to for state that is not thread-safe but the primary use is for stateless services that don't need to be disposed.

In addition to @HH's answer.

> This [UserDbContext] is created, as I understand it, by AddDbContextFactory

No, if you inject UserDbContext like you have done, you are getting the UserDbContext defined service from the DI container: whatever you've setup in your DI setup.

To get a unit of work context from the factory you need to get it from the factory by calling _factory.CreateDbContext() - see https://learn.microsoft.com/en-us/ef/core/dbcontext-configuration/#using-a-dbcontext-factory-eg-for-blazor

In you example:

[Inject] private IDbContextFactory<TDbContext> _factory { get; set; } = default!;

And then use it like this in one of your methods:

public Task ExecuteAsync()
{
    using var dbContext = _factory.CreateDbContext();

    // Do some async work on the context
}

You don't need to worry about the management of the contexts: they are not managed by DI. You get one from the factory, use it and then release it by disposing it. Dispose doesn't actually kill it, it just releases it back to the factory for reuse.

Have you considered abstracting your data management and persistence out of your components into a testable data pipeline?