Why ConnectionString param instead of injecting ADO.Net dependency?
pha3z opened this issue · 8 comments
Just found this library. I have never used Massive....so that might be why I'm confused. The Readme seems a bit lacking on explanations.
My immediate question: I wondered what is the reason for depending on a connection string instead of an ADO.NET dependency such as a DbProviderFactory instance or related class?
It doesn't seem immediately obvious to a new user how to declare what type of database is being consumed with Mighty. How do you do it?
Any thoughts? As I say, do check the docs (link above, also in the README) and not just the README itself.
It always annoyed me that the provider wasn't just part of the connection string in standard .NET. That said, I'm not 100% sure whether making it be so in Mighty was the 'right' decision..., but it made me happy, anyway! 😉
Ping if you need to. I'll leave this open for now in case anyone else has the same question...
Just to add a little more technical info here:
Mighty (like Massive) has a bit of custom code for each known provider - to make them all behave exactly the same way, e.g. in terms of DB<->C# type mapping and a few other things.
So this would never be just a matter of passing in a DbProviderFactory instance, anyway; at the very least, Mighty would have to refuse to accept this (and/or enforce passing an additional configuration parameter to set the customisation settings) if you passed in a type of DbProviderFactory which Mighty didn't already know about - which is basically what Mighty already does if you pass in a provider string which it doesn't know about.
As I recall, Dapper is similar (even though it states somewhere that it's completely DB agnostic): pure Dapper doesn't have any DB specific code but (again, IIRC) Dapper Contrib does, for the same sorts of reasons that Mighty does.
See comment in #33, in the next full version I'm planning to allow passing in provider name in a separate parameter (this will be optional, in addition to the current method of passing it in the connection string).
I can look at the same time at whether it's relatively easy to have yet another optional param, to pass in a DbProviderFactory instead. Passing both of these new parameters would be illegal (unless they're compatible?); passing either one of them would mean that no parsing of the connection string is done.
NB, as I mentioned above in this issue, Mighty is always going to need to check the identity of this, i.e. it can't just accept any DbProviderFactory, and will have to throw an exception unless it is one it knows how to support... or which you have added support for; though adding support for a new provider is enough work that if you did it, you'd probably want to submit it back to the project anyway - I hope!
@pha3z I don't know if you have any experience of whether optional parameters play well with (.NET Core) injection? (I guess if I'm going down this route I'll need to test that, in any event!)
My apologies. This completely fell off my radar. Its honestly been too long for me to even comment. I ended up not using Mighty. I was learning about ORM options out there and Mighty seemed very interesting at the time.
Sure no probs! (It would be interesting to know if lack of that feature was decisive at the time, or if anything else was - if you can remember - but totally optional if you want to comment, of course!)
This will be addressed via #29.