32

So ASP.NET Core applications have Dependency Injection built right in. And with Entity Framework Core, you can easily get a scoped DbContext instance from a controller action method.

But this is all limited to controller actions. If you need to start a long-running background task from an action that will communicate with the view in the browser by other means like WebSocket, then you suddenly have nothing at all. The background task can't use the action's DbContext because that was scoped and disposed of when the action returns.

An easy way would be to use what people call a Service Locator. This is a static copy of some IServiceProvider for later access and service resolution. (ASP.NET Core 2.1 might need a different approach as I've read in this comment.) But whereever I look, this is described as anti-pattern. It makes testing harder and obfuscates dependencies. Alright.

So what's the recommended solution for this scenario? I'm somewhere in the middle of nowhere. A background task that might even be started from a scheduler instead of a controller action. No HTTP request anywhere near. What can DI do for me here? Is there a solution without falling back to anti-patterns? I'm sure the creators of ASP.NET Core DI have thought of this.

Is there either a way to get the services resolved there, or change my architecture so that the background task itself comes out of DI somehow?

Update: Requested by a comment, an example: A controller action starts something. This will take a long time, like a network scan. The view returns with something like "Dear user, please wait while you can watch this progress bar." Work continues in the background, continually posting the progress and/or results to the browser. (The browser might also poll progress instead.) The background task needs access to the database to store the scan results. When the scan is finished, the browser can fetch it through another action. So if the background task would just use the controller action's DbContext, that would become unusable as the action has completed.

Another example is a background service that isn't related to a request at all. A service that regularly checks the database and then does something. That also needs a DbContext and has nowhere to even try to steal it.

ygoe
  • 18,655
  • 23
  • 113
  • 210
  • Please add a concrete example of the problem you are facing. – Steven Jul 29 '18 at 17:04
  • @Steven I've added some examples. – ygoe Jul 30 '18 at 06:43
  • I'm sorry, I've should have made myself more clear; I meant code examples. Can you show the relevant code for this? – Steven Jul 30 '18 at 06:52
  • I have no code ready to show. And I'm not sure what code you need to see, I think the description fits it very well. Imagine a controller action and a Task that uses a DbContext. That's all. – ygoe Jul 30 '18 at 11:40

2 Answers2

38

In that case you can only rely on the servicelocater-pattern which is an anti-pattern. Also the DbContext must be instance-per-dependency (transient) rather than scoped.

My suggestion is to inject IServiceScopeFactory which is a singleton and the beginn a scope in your background-worker that does the deed.

using (var scope = _serviceScopeFactory.CreateScope())
{
   var context = scope.ServiceProvider.GetRequiredService<DbContext>();
   // now do your work
}

There is no other. These things are not part of the mvc pipeline so they cannot be resolved on the fly. I would also suggest not to directly access the dbcontext somewhere. Wrap things in a repository and then use that repository or even wrap that repository in a so called service class. So your logic is encapsulated and your background-worker just executes things when receiving a message.

Not directly related, but ASP.NET-Core has background-worker built-in with IHostedService.

Edit 2018-07-30: As Steven suggested below, it might not always be an anti-pattern when manually resolving / initiating classes. At least not when the compositionroot is taking care of it. Here is a link he provided, where it is explained quite good.

Edit 2022-07-07:

Using the latest c# syntax and creating an async-scope is now also possible.

await using var scope = _serviceProviderFactory.CreateAsyncScope();
var context = scope.ServiceProvider.GetRequiredService<DbContext>();
// now do your work

Alternatively you can also directly inject IServiceProvider and do the very same thing.

alsami
  • 8,996
  • 3
  • 25
  • 36
  • 3
    I hate it to be pedantic, but whether or not a call to `ServiceProvider.GetService` is an implementation of the Service Locator anti-pattern, depends on from *what location* it is used. If called from inside the [Composition Root](https://freecontent.manning.com/dependency-injection-in-net-2nd-edition-understanding-the-composition-root/) it is *not* a Service Locator. But when used *outside* the Composition Root, it is a Service Locator. For more info, see [this](https://blog.ploeh.dk/2011/08/25/ServiceLocatorrolesvs.mechanics/). – Steven Jul 30 '18 at 12:26
  • 1
    Hey Steven. Thank you for your feedback. I will read into that and update the answer accordingly. – alsami Jul 30 '18 at 14:29
  • You are missing a .Dispose() for the context object. This will leak. Or better using (var context = ...) { // do your work } – Morten Frederiksen Dec 07 '21 at 09:38
  • No it won't because everything resolved in the scope will automatically be disposed with the scope. – alsami Dec 07 '21 at 13:02
0

I found this Q&A when I was looking at moving a timed process to a background service while updating my .Net 4.8 project to Net 6. It seems that you no longer have to configure your dbcontext to be transient as alsami's answer states. At least, I no longer get the error: singleton cannot consume scoped.

Implicitly sharing DbContext instances via dependency injection

Using dependency injection, this can be achieved by either registering the context as scoped, and creating scopes (using IServiceScopeFactory) for each thread, or by registering the DbContext as transient (using the overload of AddDbContext which takes a ServiceLifetime parameter).

midohioboarder
  • 438
  • 5
  • 14