EF Core .NET 6 - Access DbContext from singleton service
Hi,
I've started using EF Core (.NET 6) since a few weeks, but I'm a bit confused about the following aspects:
- I keep reading the dbContext should be scoped, and that make sense.
- If I want service A to access dbContext, service A needs to be scoped as well, it cannot be a singleton. And I could understand this: since a service in injected in the constructor, A needs to be re-instantiated every time it needs to access dbContext so that each time a new instance of dbContext is injected into it
- Controllers are transient (or scoped, not sure), so when a request come, the controller is instantiated passing to it a service A instance which in turn is instantiated on the fly passing an instance of dbcontext to it.
Until here everything makes sense.
I have a scenario where I have a long-running task (singleton service B) that periodically needs to write data to the database. How am I supposed to do this, since I cannot inject scoped service A into singleton service B?
From this post https://stackoverflow.com/a/58989132/7035167 it seems like I should have a factory of service A objects and, everytime B needs to access database, I should generate an instance of A, use it to write on database and then dispose it.
However it seems to me that this defeats the whole purpose of the dependency injection concept: from what I've understood, I should not instantiate an object that is injected somewhere else. Furthermore, if I was to instantiate service A, I should first instantiate dbContext too, and I think this is not the correct way of doing things.
Stack Overflow
Use DbContext in ASP .Net Singleton Injected Class
I need to access my database in a Singleton class instantiated in my Startup class. It seems that injecting it directly results in a DbContext that is disposed.
I get the following error:
Cannot
9 Replies
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
I'll second
IDbContextFactory<TContext>. Injecting a factory is how you go about letting the class create multiple instances on-demand of a type.Good to know DbContextFactory, thanks.
Do you think that instantiating every time only DbContextFactory and not a service A that in turns require DbContext would be relevant performance-wise?
Ok, thanks. I'm quite new to this stuff (ef core, different kind of lifetimes etc)
I wouldn't worry about perf here. It's a common enough pattern in desktop apps, but not sure how well it works perf-wise with web in particular. I doubt the potential overhead is worth worrying about vs the cost of a DB operation.
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
In this case I always go with creating my own scope in the DI whenever a singleton service needs to do something
you can get anything from the scope, so even a service that itself gets a DbContext from the Service Provider
yeah actually I don't think I need it either, even though the application take care of many different aspects (continuously encode images from camera, communicate with OT devices...), but it's not like it should not be able to do this.
I was just trying to better understand how much this continuous instantiation of object would "cost". But since it's the standard way to do things, I suppose it's affordable...
ok thanks
Unknown User•3y ago
Message Not Public
Sign In & Join Server To View
That's something to think about, thanks