Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
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 type-enhancement
Milestone
5.0.0

Comments

@AndriySvyryd
Copy link
Member

AndriySvyryd commented Oct 24, 2019 •
edited
Loading

This would make using short-lived contexts easier.
Related: #19610
@AndriySvyryd AndriySvyryd mentioned this issue Oct 24, 2019
Open
@ajcvickers ajcvickers added this to the Backlog milestone Oct 25, 2019
@ajcvickers ajcvickers modified the milestones: Backlog, 5.0.0 Nov 20, 2019
@AndriySvyryd
Copy link
Member Author

See https://github.com/vany0114/EF.DbContextFactory

@AndriySvyryd AndriySvyryd mentioned this issue Jan 28, 2020
Closed
@jzabroski
Copy link

jzabroski commented Jan 28, 2020 •
edited
Loading

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.

This was referenced Feb 14, 2020
Closed
Closed
@ajcvickers ajcvickers mentioned this issue Mar 6, 2020
Closed
@ajcvickers ajcvickers mentioned this issue Mar 15, 2020
Closed
@AndriySvyryd AndriySvyryd removed their assignment Jun 10, 2020
ajcvickers added a commit that referenced this issue Jun 12, 2020
@ajcvickers
Add AddDbContextFactory to allow registering a factory for creating c…
33d8d30 
…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.
This was referenced Jun 12, 2020
Merged
Closed
ajcvickers added a commit that referenced this issue Jun 13, 2020
@ajcvickers
Add AddDbContextFactory to allow registering a factory for creating c…
d814eba 
…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
@ajcvickers
Avoid using ActivatorServices for common DbContext constructor
5e4f0a0 
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 mentioned this issue Jun 13, 2020
Merged
ajcvickers added a commit that referenced this issue Jun 13, 2020
@ajcvickers
Avoid using ActivatorServices for common DbContext constructor
dbf969b 
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
@ajcvickers
Avoid using ActivatorServices for common DbContext constructor (#21254)
63d84c9 
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
@AndriySvyryd AndriySvyryd mentioned this issue Jul 4, 2020
Closed
@AndriySvyryd AndriySvyryd mentioned this issue Jul 29, 2020
Closed
@AndriySvyryd AndriySvyryd mentioned this issue Sep 12, 2020
Closed
@ajcvickers ajcvickers modified the milestones: 5.0.0-preview7, 5.0.0 Nov 7, 2020
@ajcvickers ajcvickers removed their assignment Sep 1, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
area-dbcontext type-enhancement
Projects
None yet
Milestone
5.0.0
Development

Successfully merging a pull request may close this issue.

Add AddDbContextFactory to allow registering a factory for creating contexts dotnet/efcore
3 participants
@jzabroski @ajcvickers @AndriySvyryd