It is 'ok' depending on how you define ok. If you work in a shop
running only SQL server for instance and don't plan changin in the
foreseeable future, I would however advise against. The more generic
you write your code, obviously the more flexible it will be. If
possible though, you want to use a provider specific to the db back
end you are using. Basically what you are trying to use is a factory
pattern and it can be very valuable, but the value is relative to the
situation at hand.
The real performance hit comes when you don't specificy a provider at
any point and only use IDBxxx , although once again, the performance
hit may be negligible depending on size, structure etc.
Well, no. You can't "only use IDBxxx", because at some point you have
to create an actual object, and you can't instantiate an interface. So
the IDbConnection object is *always* going to be some kind of
provider-specific object.
In response to the original question, no, there's no late binding
involved and no performance hit to making calls against the interface
rather than against the provider-specific object.
Ironically, though, I agree with William that it's generally a bad idea
to do this unless you absolutely have to switch providers at runtime
It's much better IMHO to keep your data layer as small as possible, so
that you can switch in another one without too much trouble (in fact,
I'd probably suggest multiple data layers even if you did need to switch
providers at runtime). The problem is that the factory class has a
tendency to grow more complex than you'd expect. Handling simple things
like parameterized queries can get fairly complex when trying to use
IDbCommand and IDataParameter, and handling subtle SQL differences can
add up quickly.
