Port over DbProviderFactories class

[FransBouma]

I have seen no info about this with respect to .NET Core, and it's a crucial element for (micro) ORMs and data-access libraries. The .NET full API for DbProviderFactory contains usage of DataTable, so I recon that's not going to be ported anytime soon, but there's a bigger problem: most provider factories are defined in machine.config, which with 'bcl per app' isn't going to fly anymore.

Have there been any design thoughts on this? Will .NET core have DbProviderFactory machinery so an ORM can obtain the factory from a central API (I couldn't find the API of .NET full in corefx at the moment), and create ADO.NET elements using that factory?

Or is this in limbo just like DataTable (https://github.com/dotnet/corefx/issues/1039)

[YoungGah]

@FransBouma, you are correct that DataTable is not the only design issue we need to solve here to make DbProviderFactory and DbProviderFactories to work. The registration mechanism for Full Framework was through config files. For NET Core, we will have to come up with a new registration mechanism, but we don't have concrete design. This will be addressed post v1.0.

[FransBouma]

Do realize that if this is introduced post v1.0, the v1.0 runtime will be a bit useless for ORMs: without a providerfactory, it's much harder to write db agnostic code that doesn't reference ADO.NET specific providers. .NET 1.x has learned a hard lesson: taking dependencies on ADO.NET providers in an ORM is a versioning nightmare. So not having any providerfactory support whatsoever (not even in the app config file or whatever it's called in corefx) is a showstopper.

[davidfowl]

Just going to +1 this and say it should be all code based configuration. That's one thing I hated about those APIs in the past.

[schotime]

I have just added the DbProviderFactory as a constructor parameter now and it can be passed in when you reference your particular database driver. Eg for sql server. SqlClientFactory.Instance

It's a suitable workaround for now. I also agree with @davidfowl about a new code mechanism. However now that I think about it. You would have to register that in the app anyway so might as well just do what ive done.

[YoungGah]

@davidfowl and @schotime, yes, the current thinking is to provide code based configuration.

[eschneider999]

My micro orm Symbiotic is at %97+ to .NET Core compatibility. Just need DbProviderFactory and some config junk.

[kkurni]

Here our proposal for DbProviderFactories for corefx by using Code based Configuration
https://github.com/dotnet/corefx/issues/6476

As a background in .NET Framework DbProviderFactories is a configuration based mechanism which can be used to resolve a DbProviderFactory instance that is registered in configuration (most often in machine.config) based on a string containing a well-known “provider invariant name”. Applications using this mechanism generally don’t need to depend on the provider directly because the provider is also registered globally in the GAC.

As you probably know in CoreFx, there will be No GAC and global configuration anymore.
This make the concept of DbProviderFactories become less useful.
And for dependency injection purposes, there are lots of better alternative. e.g Contruction injection as @schotime mentioned, or using simple dictionary or your favorite dependency injection mechanism.

@FransBouma, @eschneider999, @schotime , @davidfowl or others, Please let us know whether
this DbProviderFactories will still be useful for you in Corefx context.
https://github.com/dotnet/corefx/issues/6476

[kkurni]

CC @giancarloa

[FransBouma]

I understand the lack of GAC / machine.config makes it all a bit problematic and therefore would fall back onto the mechanism of the app's config file configuration for DbProviderFactory (similar to what is possible in .NET full today), and if configuration in CoreFX is done through code, not config files then this is the wisest solution.

At first glance I see no way to obtain a factory when I have just an invariant name? As you register the factory under a name with DbProviderFactoriesConfiguration but that class stores the registered factory internally and there's no way to obtain the registered factory? Your proposal specifies contract changes, but it's unclear to me what changes where.

There's another problem, which is perhaps less of your concern, and that's factory overwriting is not supported with your solution. ADO.NET profilers (like Glimpse, EFProf and also ORM Profiler) tend to overwrite the static table in .NET full with their own factories which intercept any call to the factory instance and create wrapping elements instead to intercept calls to ADO.NET elements. Your proposed solution doesn't offer that flexibility anymore.

[kkurni]

@FransBouma you can access your registered factory the same ways as the old ways in .NET Frameworks.

DbFactories.GetFactory(string providerInvariantName);
DbFactories.GetFactory(DbConnection connection);

In CoreFx, you will need to use DbProviderFactoriesConfiguration to register your provider.

DbProviderFactoriesConfiguration.Add("Sytem.Data.SqlClient", () => SqlClientFactory.Instance);

But in .NET Frameworks, you don't need to do anything, it will read from the machine config as it is.