Use service to create connections

[ajcvickers]

Rather than calling, for example, new SqlConnection() directly. Using the provider factory makes us compatible with wrapping ADO.NET providers. However, we will need to be able to obtain the provider factory in some way. Since this code is already provider-specific we could assume knowledge of well-known provider invariant names. We could also punt on this and tell people to always use explicitly created connections if they need wrapping ADO.NET providers.

[rowanmiller]

We should introduce a service for this, so that we aren't creating connections explicitly.

[dazinator]

we will need to be able to obtain the provider factory in some way.

I'd be very interested in this feature, as I have an ADO.NET provider implementation that supports standard T-SQL. Currently, I have to create a whole EF provider for this, where as if I could get EF to just use the correct DbProviderFactory- that's pretty much all I would need at this stage.

Could you make it:

1. Find some way to either inspect the connection string to grab the invariant name, or, provide some extension method / configuration option that could be used to tell EF the invariant name to use.
2. Based on the above, resolve the appropriate dbproviderfactory - i.e `DbProviderFactories.GetFactory("invariant name") and use that..

[dazinator]

we could assume knowledge of well-known provider invariant names.

Can you make it so I am still able to plugin in my "non well known" ado.net provider - i.e so that any "well known" provider invariant names isn't the exclusive list that EF will work with.. :)

[divega]

`DbProviderFactories.GetFactory("invariant name")

@dazinator In the "Core" version of ADO.NET (i.e. System.Data.Common and System.Data.SqlClient packages) there is still the concept of provider factories but not the concept of a provider factory registry in configuration, so we cannot depend on that. We could build a service within EF to resolve invariant names to provider factories so that you can register your replacement, but at that point I don't know if we really need the indirection, e.g. there could be a more direct way to tell the EF provider for SQL Server to use a different provider factory.

BTW, we haven't prioritized this for RTM because we are focusing on just getting things working with SQL Server, but this is an important part of our design that we definitively plan to focus on getting right later.

[dazinator]

@divega ahh ok I understand. Sounds like it's all in hand, I'll look forward to taking advantage of that capability once it's added! Cheers.

[fitzchak]

@divega Is there any progress to implementing a service to register a different factory? We need a way to do this in order to add support for profiling Entity Framework Core using Entity Framework Profiler.

[NickCraver]

I was investigating making a MiniProfiler.EntityFrameworkCore package for easily hooking up profiling...but I can't see how to do this. If we had a service, we could hopefully replace it and override the connection with a ProfiledDbConnection. As it stands, I'm not sure how I'd even instruct a user on how to do this, even manually.

Is this planned? Or am I missing an obvious hook here for profiling?

[ajcvickers]

Should be possible to do this with an IDbConnectionInterceptor. May also need: #21578

[AndriySvyryd]

Related: #28266

[ajcvickers]

Any remaining work covered by issues referenced above.