When building new app in .NET Core 3 (or above), is there any reason to still use AddDbContext, instead of AddDbContextPool? If so, shouldn't AddDbContext be marked obsolete at this point?
Asked
Active
Viewed 109 times
0
Rand Random
- 7,300
- 10
- 40
- 88
Ish Thomas
- 2,270
- 2
- 27
- 57
-
2Does this answer your question? [AddDbContext or AddDbContextPool](https://stackoverflow.com/questions/48443567/adddbcontext-or-adddbcontextpool). That references ASP.NET Core 2, but your question gives no reason why 3 should be different -- note that the accepted answer implies the semantics are sufficiently different that the uses are not interchangeable and hence there's still a case for both. – Jeroen Mostert May 06 '20 at 18:33
-
Thanks. As I'm reading this, it looks like the only reason to still use `AddDbContext` is when you use private variables inside DbContext that you don't want to share. Otherwise you should always use DbContextPool (better performance). I'm not 100% sure, if I missed something though – Ish Thomas May 06 '20 at 18:37
-
@IshThomas That should be enough for not making `AddDbContext` "obsolete". And having private fields or constructor injected state is de facto standard for single database multi-tenant db contexts. – Ivan Stoev May 06 '20 at 18:54
-
Use AddDbContext. Pooling DbContext instances is probably the wrong way to solve your performance issues. Try caching HTTP responses first. – bricelam May 07 '20 at 20:15
-
@bricelam I have an endpoint where I need to perform 5 parallel DbContext queries. So in old fashion way I have `AddDbContext` and simple factory, where I "new-up" new DbContexts.I thought Pooling is the way to go nowadays, no? – Ish Thomas May 07 '20 at 22:39
-
1A factory is perfect for this scenario. We (the EF team) are considering adding one by default when you call AddDbContext for those times when you need a new instance inside of a request scope. Pooling might help with perf in very specific scenarios, but it's unrelated to service scopes – bricelam May 08 '20 at 15:57