I am a Java retread pretty a new comer to C#. I am wishing to avoid trouble after i create a lot of DML code within the next couple of days.

I am accustomed to the thought of using JDBC's abstract classes like Connection, Statement, and so on. C# offers similar abstract classes like DbConnection, DbCommand, and so on, within the System.Data.Common namespace.

But, the majority of the good examples I have seen -- in MS documentation along with other books -- make use of the concrete classes: SqlConnection, OracleCommand, etc. This type of concreteness even turns up within the mySQL documentation.

What's the best practice in this region? Can there be some strong reason to select concrete table-server-specific instead of abstract classes for this function? (I am conscious of the risks of downcasting abstract to concrete, obviously).

The abstract classes weren't area of the first versions from the framework, these were introduced in version 5.. Lots of good examples were written before that, or derive from good examples which were written before that.

Using concrete or abstract classes is really a few taste. It is a nice idea to create code that may use any database, but my experience is you don't switch database systems very frequently, and when you need to do you will find a lot of changes you need to do this it does not matter much should you used abstract classes or otherwise.

Most database-specific ADO.Internet classes have extra overloads and/or techniques and qualities which are specific for your database driver.

Using concrete classes like SqlConnection and OracleConnection causes it to be simpler to gain access to driver-specific features.

Generally, when guess what happens database your organization or else you are utilizing, you target to that particular specific database type. Knowing its Oracle, then you apply the Oracle related classes, if it is SQLClient, then you definitely use SqlClient and so forth.

Now, if you're unsure which sort it's, you would then be taking a generic/generalized type of reference, to ensure that you are able to achieve your ultimate goal without needing to be worried about the database type. The opposite way round could be, writing a lot of conditional claims to determine the kind of database after which perform procedures according to it.

A typical scenario that will help you understand could be: If you're writing code, to ensure that your consumer can alter the config file and enter an association string for connecting towards the database, which offer will you be utilizing? This is actually the place where DbFactory and it is relevant classes come handy, where rather than writing portions of code, you employ the generic class(kind of I suppose) to deal with everything.

Bear in mind, when do target a particular provider, you'll have better performance(as DbFactory needs to resolve your provider internally before handling it), but when you're unclear about the consumer provider, your code could be large in addition to 't be efficient.

Visiting your other question: Abstract or Concrete. Its up to you and also again, its SCENARIO based. The benefit of abstract is the fact that, you are able to Pressure/Connect the customer against rules(as an interface) in addition to you are able to generalize things in addition to utilize type casting (much like concrete classes) to gain access to subclass techniques to behave (check up on this subject if you're able to. While using run-time polymorphism, you should use one object and call a technique that has different implementations in various classes subclassed for this parent class, which you won't ever be concerned about - for example calculation of great interest maybe Simple Interest and Compound interest for any bank, that are calculated through the particular class- however, you dont worry about it, because you just say - GetInterest() and boom!).

Clubbing both together, I'd say, inside a scenario in which you have no idea the kind of Database getting used through the consumer, and never understanding the connection string, you might like to pressure the consumer to implement your class, IMPLEMENT your abstract approach to initialize the bond string after which carry out the necessary operation to provide an output.

Hope it will help.