oracle 为什么不用 DbConnection 而不是 SqlConnection 或 OracleConnection？

Why not DbConnection instead of SqlConnection or OracleConnection?

提问by O. Jones

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.

我是 C# 的新手 Java 翻新者。我希望在接下来的几周内编写大量 DML 代码时不会遇到麻烦。

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.

我已经习惯了使用 JDBC 的抽象类（如 Connection、Statement 等）的想法。C# 在 System.Data.Common 命名空间中提供了类似的抽象类，如 DbConnection、DbCommand 等。

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.

但是，我在 MS 文档和其他书籍中看到的大多数示例都使用了具体的类：SqlConnection、OracleCommand 等。这种具体性甚至出现在 mySQL 文档中。

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).

该领域的最佳实践是什么？为此目的，是否有充分的理由选择特定于表服务器的具体类而不是抽象类？（当然，我知道将抽象降级为具体的危险）。

回答by Guffa

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.

抽象类不是框架的第一个版本的一部分，它们是在 2.0 版中引入的。很多例子都是在那之前写的，或者是基于之前写的例子。

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.

使用具体或抽象类主要是一种品味问题。编写适用于任何数据库的代码是一个不错的主意，但我的经验是您不会经常切换数据库系统，如果您切换数据库系统，那么您需要做的更改太多，这无关紧要如果您使用抽象类与否。

回答by Philippe Leybaert

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

大多数特定于数据库的 ADO.NET 类都有额外的重载和/或特定于该数据库驱动程序的方法和属性。

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

使用 SqlConnection 和 OracleConnection 等具体类可以更轻松地访问特定于驱动程序的功能。

回答by Nabil Shaik

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.

一般而言，当您知道您的公司或您正在使用什么数据库时，您的目标是该特定数据库类型。如果你知道它的Oracle，那么你使用Oracle相关的类，如果你知道它的SQLClient，那么你使用SqlClient等等。

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.

一个帮助您理解的常见场景是：如果您正在编写代码，以便您的最终用户可以更改配置文件并输入连接字符串以连接到数据库，您会使用哪个提供？这是 DbFactory 及其相关类派上用场的地方，您无需编写代码块，而是利用通用类（我猜是这样）来处理所有事情。

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.

请记住，如果确实针对特定的提供者，您将获得更好的性能（因为 DbFactory 必须在处理之前在内部解析您的提供者），但是如果您不确定最终用户提供者，那么您的代码也会很大因为效率不高。

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!).

来到你的另一个问题：抽象或具体。它取决于你，它是基于场景的。抽象的优点在于，您可以根据规则（如接口）强制/绑定客户端，也可以概括事物以及利用类型转换（类似于具体类）来访问子类方法来做某事（检查如果可以的话，关于这个主题。使用运行时多态性，您可以使用一个对象并调用一个方法，该方法在子类到该父类的不同类中具有不同的实现，您永远不需要担心 - 例如利息计算也许银行的单利和复利是由各自的类计算的——但你并不关心它，因为你只是说——GetInterest() 和繁荣！）。

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.

希望能帮助到你。