An EF provider potentially now provides four services:
DbProviderServices -- main EF provider
DbSpatialServices -- spatial services; obtained from main provider or registered globally
MigrationSqlGenerator -- SQL gen for migrations; registered per invariant; can be overridden in migrations config
IHistoryContextFactory -- registered per migrations context type or as default
It would make it easier for provider writers if they could register one thing in the config file (say just DbProviderServices) and it would resolve all the other services as dependencies. (This would have to exclude the global spatial provider.)
Comments: Second change related to this item: 725c42090371 OneProviderToRuleThemAll (Allow single registration of a DbProviderServices to resolve additional services) This change makes DbProviderServices implement IDbDependencyResolver so that when a provider is registered either in DbConfiguration or in the config file it can be used to resolve additional services. For example, instead of registering the Migrations SQL Generator separately, the registered DbProviderServices can now override GetService to return the SQL generator. Not all providers will need to resolve all potentially provider-dependent services since the default service implementation may work just fine. For example, some providers may need to create a new implementation of IContextKeyFactory, while others (including both SQL Server and SQL Compact) can just use the default. The mechanism is also not limited to services that are known to be provider-specific, thereby giving providers greater flexibility in configuring services where some detail doesn't work well for that provider. The implementation here depends on a new concept of a "secondary resolver". This is a dependency resolver that sits in the chain as normal, but when added is placed near the bottom of the chain (just above the root resolvers) such that it can resolve services that have not already been resolved without getting in the way of application-specific configuration. In effect, it allows code from outside of EF to change root resolvers. Several things still remain to be done here: - Update the PowerShell commands to make the most-recently added provider the default such that it will get a chance to resolve non-provider-specific services before other providers. - Consider whether or not the registration of the default connection factory in the config is still required. - Consider changes to DbProviderServices to make resolution of execution strategies happen only through this general mechanism rather than using the specific methods that were previously added. - Potentially change spatial resolution to resolve provider-specific spatial services before global spatial services. - Updating provider documentation to reflect these changes
DbProviderServices -- main EF provider
DbSpatialServices -- spatial services; obtained from main provider or registered globally
MigrationSqlGenerator -- SQL gen for migrations; registered per invariant; can be overridden in migrations config
IHistoryContextFactory -- registered per migrations context type or as default
It would make it easier for provider writers if they could register one thing in the config file (say just DbProviderServices) and it would resolve all the other services as dependencies. (This would have to exclude the global spatial provider.)
Comments: Second change related to this item: 725c42090371 OneProviderToRuleThemAll (Allow single registration of a DbProviderServices to resolve additional services) This change makes DbProviderServices implement IDbDependencyResolver so that when a provider is registered either in DbConfiguration or in the config file it can be used to resolve additional services. For example, instead of registering the Migrations SQL Generator separately, the registered DbProviderServices can now override GetService to return the SQL generator. Not all providers will need to resolve all potentially provider-dependent services since the default service implementation may work just fine. For example, some providers may need to create a new implementation of IContextKeyFactory, while others (including both SQL Server and SQL Compact) can just use the default. The mechanism is also not limited to services that are known to be provider-specific, thereby giving providers greater flexibility in configuring services where some detail doesn't work well for that provider. The implementation here depends on a new concept of a "secondary resolver". This is a dependency resolver that sits in the chain as normal, but when added is placed near the bottom of the chain (just above the root resolvers) such that it can resolve services that have not already been resolved without getting in the way of application-specific configuration. In effect, it allows code from outside of EF to change root resolvers. Several things still remain to be done here: - Update the PowerShell commands to make the most-recently added provider the default such that it will get a chance to resolve non-provider-specific services before other providers. - Consider whether or not the registration of the default connection factory in the config is still required. - Consider changes to DbProviderServices to make resolution of execution strategies happen only through this general mechanism rather than using the specific methods that were previously added. - Potentially change spatial resolution to resolve provider-specific spatial services before global spatial services. - Updating provider documentation to reflect these changes