-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a performant way to register a context factory in DI #18575
Comments
Currently, we ask each |
…ontexts Fixes #18575 Mostly this is copied from @JeremyLikness's sample, with tests added. It evolved a bit as I was testing. Most significantly, we now register an IDbContextFactory interface, for which we provide a default implementation. This allows the factory to be replaced by one specific for the application, which can be more performant because it doesn't use ActivatorUtilities. Overloads have been added for this. I believe we can also add overloads to allow the factory to resolve from a context pool, but I will file a new issue for this.
…ontexts (#21246) Fixes #18575 Mostly this is copied from @JeremyLikness's sample, with tests added. It evolved a bit as I was testing. Most significantly, we now register an IDbContextFactory interface, for which we provide a default implementation. This allows the factory to be replaced by one specific for the application, which can be more performant because it doesn't use ActivatorUtilities. Overloads have been added for this. I believe we can also add overloads to allow the factory to resolve from a context pool, but I will file a new issue for this.
Improvement to #18575 This change checks if the DbContext has the usual constructor taking just options: ```C# MyContext(DbContextOptions<MyContext> options) ``` If it does, then we create a delegate (once in a singleton service) and use that to create context instances. This avoids using ActivatorServices and falling out of constructor injection (other than the delegate) for the common case.
Improvement to #18575 This change checks if the DbContext has the usual constructor taking just options: ```C# MyContext(DbContextOptions<MyContext> options) ``` If it does, then we create a delegate (once in a singleton service) and use that to create context instances. This avoids using ActivatorServices and falling out of constructor injection (other than the delegate) for the common case.
Improvement to #18575 This change checks if the DbContext has the usual constructor taking just options: ```C# MyContext(DbContextOptions<MyContext> options) ``` If it does, then we create a delegate (once in a singleton service) and use that to create context instances. This avoids using ActivatorServices and falling out of constructor injection (other than the delegate) for the common case.
This would make using short-lived contexts easier.
Related: #19610
The text was updated successfully, but these errors were encountered: