Skip to content
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

Closed
AndriySvyryd opened this issue Oct 24, 2019 · 2 comments · Fixed by #21246
Closed

Add a performant way to register a context factory in DI #18575

AndriySvyryd opened this issue Oct 24, 2019 · 2 comments · Fixed by #21246
Labels
area-dbcontext closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Milestone

Comments

@AndriySvyryd
Copy link
Member

AndriySvyryd commented Oct 24, 2019

This would make using short-lived contexts easier.
Related: #19610

@AndriySvyryd
Copy link
Member Author

@jzabroski
Copy link

jzabroski commented Jan 28, 2020

Hi @AndriySvyryd

Currently, we ask each T in an IRepository<T> who their IDbContext is, which requires looping over all entity registrations - so this should solve two problems with one abstraction. This context factory sounds like a nice improvement, and it avoids directly exposing Func<T> which, based on my recent reading of old 2016 conversations between David Fowler and SImpleInjector team, ASP.NET team does not want to do.

@AndriySvyryd AndriySvyryd removed their assignment Jun 10, 2020
ajcvickers added a commit that referenced this issue Jun 12, 2020
…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.
@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Jun 12, 2020
ajcvickers added a commit that referenced this issue Jun 13, 2020
…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.
ajcvickers added a commit that referenced this issue Jun 13, 2020
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.
ajcvickers added a commit that referenced this issue Jun 13, 2020
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.
ajcvickers added a commit that referenced this issue Jun 13, 2020
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.
@ajcvickers ajcvickers modified the milestones: 5.0.0, 5.0.0-preview7 Jun 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-dbcontext closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants