Update to Reduce magic in the interaction of EF Core and DI #4750
Conversation
See issue #4668. This is an update following a discussion yesterday that moves all configuration onto DbContextOptions and makes this the only object passed to the DbContext constructor. This allows the builder pattern that already exists for DbContextOptions to be used for external services and for setting the internal service provider. AddDbContext does this automatically for external services, but a DbContextOptions object can also be easily built and either configured in DI or passed directly to the context with new. In addition, the UseMyProvider methods have been updated to use nested closure for provider-specific configuration. This makes for a very nice chaining story. There is a new overload of AddDbContext that makes the application service provider available to teh configuration delegate. This is rarely needed, but one use is to set the application service provider to be used as the internal EF service provider if this is needed/desired. Still to do: - Look at negative cases when services are not setup and create better exception messages. - Rename AddSqlServer, etc to AddEntityFrameworkSqlServer, etc. - Extract diagnostics as one of the external services on DbContextOptions.
| /// <returns> The options builder so that further configuration can be chained. </returns> | ||
| public static DbContextOptionsBuilder UseSqlServer( | ||
| [NotNull] this DbContextOptionsBuilder optionsBuilder, | ||
| [NotNull] string connectionString, |
There was a problem hiding this comment.
Should this just happen in the action now? Or, is this the pattern for required config?
There was a problem hiding this comment.
Yep. This is the pattern for required config.
|
Question: Do we still need the DbContextOptions/Builder that are generic on TContext? What are they used for? |
|
Creating DbContextOptions that are specific to a given context type such that an application can have multiple context types registered in D.I. and have each one resolve the correct options. |
|
|
🎉
|
Merged |
|
Referencing #4784 This change has caused application service provider resolution to fail when adding plain DbContext (rather than subclassed one) because the default constructor is preferred. May be for DependencyInjection |
Because when people use the same service provider for both the application and our internal services and don't create a derived DbContext class, then the two registrations can often collide. See #4750. The fix is to use the type ICurrentDbContext internally which wraps the context for the current scope.
|
@rowanmiller One could argue that this change should be emphasized on the https://github.com/aspnet/Announcements repo, as it breaks code when one resolves the db provider in As |
See issue #4668. This is an update following a discussion yesterday that moves all configuration onto DbContextOptions and makes this the only object passed to the DbContext constructor. This allows the builder pattern that already exists for DbContextOptions to be used for external services and for setting the internal service provider. AddDbContext does this automatically for external services, but a DbContextOptions object can also be easily built and either configured in DI or passed directly to the context with new.
In addition, the UseMyProvider methods have been updated to use nested closure for provider-specific configuration. This makes for a very nice chaining story.
There is a new overload of AddDbContext that makes the application service provider available to teh configuration delegate. This is rarely needed, but one use is to set the application service provider to be used as the internal EF service provider if this is needed/desired.
Still to do: