Using DI with Razor Components lead to holding on to resources for long times

[matthewDDennis]

If I understand the way DI is used in Razor Components, Scoped services have a lifetime of the connection.
Wouldn't this, especially in the case of DbContexts, leave a lot of resources alive for long times and result in resource, such as SQL connections, or memory starvation if there are MANY concurrent requests?

[mkArtakMSFT]

Thanks for contacting us, @matthewDDennis.
@rynowak, can you please answer this question? Thanks!

[mkArtakMSFT]

Seems related: #5496

[mkArtakMSFT]

@matthewDDennis, you're right about scoped services to use resources throughout the lifetime of the connection, so it's important to be mindful about the usage of those resources.
Also, we plan to implement a mechanism to evict idle connections so resources aren't wasted. We track that work as part of #6358.

[vertonghenb]

Related: aspnet/Blazor.Docs#400
In some cases Scoped is really wanted, for example to keep AppState objects to hold the state of the UI for the entire scope of the connection. However for EF etc, I wouldn't advise to use a Scoped DbContext but rather use a transient one.

[Andrzej-W]

@matthewDDennis as @vertonghenb has already written you should use transient scope. As long as your business logic is within single function it is probably not a problem. Otherwise you have to get your context in one place and then pass it as a parameter to other functions or constructors.

Warning: you should get your context in a function and assign it to local variable in that function. Don't use automatic constructor injection and don't assign transient context to the field in a class. In Razor Components your class will be life at least as long as user interacts with current page. I don't use Razor Components, but I'm almost sure that I'm right here.