Why not DbConnection instead of SqlConnection or OracleConnection?

I'm a Java retread pretty new to C#. I'm hoping to stay out of trouble when I crank out a bunch of 开发者_运维知识库DML code in the next few weeks.

I'm used to the idea of using JDBC's abstract classes like Connection, Statement, and the like. C# offers similar abstract classes like DbConnection, DbCommand, and so forth, in the System.Data.Common namespace.

But, most of the examples I've seen -- both in MS documentation and other books -- use the concrete classes: SqlConnection, OracleCommand, etc. This kind of concreteness even shows up in the mySQL documentation.

What is the best practice in this area? Is there some strong reason to choose concrete table-server-specific rather than abstract classes for this purpose? (I'm aware of the hazards of downcasting abstract to concrete, of course).

The abstract classes were not part of the first versions of the framework, they were introduced in version 2.0. A lot of examples were written before that, or are based on examples that were written before that.

Using concrete or abstract classes is mostly a matter of taste. It's a nice idea to write code that could work with any database, but my experience is that you don't switch database systems very often, and if you do there are so many changes that you need to do that it doesn't matter much if you used abstract classes or not.

Most database-specific ADO.NET classes have extra overloads and/or methods and properties that are specific for that database driver.

Using concrete classes like SqlConnection and OracleConnection makes it easier to access driver-specific features.

In general, when you know what database your company or you are using, you target to that specific database type. If you know its Oracle, then you use the Oracle related classes, if its SQLClient, then you use SqlClient and so on.

Now, if you are unsure which type it is, then you would be going for a generic/generalized form of reference, so that you can achieve your goal without having to worry about the database type. The other way round would be, writing a bunch of conditional statements to check the type of database and then perform operations as per it.

A common scenario to help you understand would be: If you are writing code, so that your end user can change the config file and enter a connection string to connect to the database, which provide would you be utilizing? This is the place where DbFactory and its relevant classes come handy, where instead of writing chunks of code, you utilize the generic class(sort of I guess) to handle everything.

Keep in mind, that if do target a specific provider, you will have better performance(as DbFactory has to resolve your provider internally before handling it), but if you are unsure of the end user provider, then your code would be large as well as not be efficient.

Coming to your other question: Abstract or Concrete. Its upto you and again, its SCENARIO based. The advantage of abstract is that, you can FORCE/TIE up the client against rules(like an interface) as well as you can generalize things as well as utilize type casting (similar to concrete classes) to access subclass methods to do something (check on this topic if you can. Using the run-time polymorphism, you can use one object and call a method which has different implementations in different classes subclassed to this parent class, of which you never need to worry about - such as calculation of interest maybe Simple Interest and Compound interest for a bank, which are calculated by the respective class- but you dont care about it, since you just say - GetInterest() and boom!).

Clubbing both together, I would say, in a scenario where you dont know the type of Database being used by the end user, and not knowing the connection string, you might want to force the end user to implement your class, IMPLEMENT your abstract method to initialize the connection string and then perform the necessary operation to give an output.

Hope it helps.