ADO.NET为底层数据库提供了不同的连接对象的特定实现。换言之，为了连接到微软SQL Server数据库，要通过特定的名为SqlConnection的类。实际上，所有SQL Server特有的类都位于System.Data.SqlClient命名空间下。类似地，所有Oracle相关的类都位于System.Data.Oracle- Client命名空间下。

这些针对特定数据库的特定实现被称为.NET数据提供程序。如图1-4所示。

图1-4  .NET数据提供程序及其在更大范围的图示中的位置

现代计算领域为我们提供了很多流行的数据库来选择。正如本章开始介绍的那样，这些数据库可以是基于服务器的或基于文件的。基于服务器的数据库更为稳定，也能更好地支持多个并发用户；而基于文件的数据库在大规模的客户端安装了应用程序的情况下更容易部署和管理。但是，一定要注意这是一般情况；例如，用微软的SQL Server 2005，你可以在拥有成熟的基于服务器的数据库的同时，又能与易用的基于文件的系统进行通信。

在有多种可供选择的数据源的情况下，ADO.NET需要支持各种不同的数据源。每种数据源都可能具有其各自的特性或功能。因此，ADO.NET支持一个提供程序模型。针对一个特定数据源的ADO.NET提供程序可以定义为一个命名空间下的一组类，这些类专门针对这种特定的数据源。

换言之，针对特定的数据源，你需要有特定的.NET数据提供程序。这种差别在OleDb和ODBC之间有些含糊不清，这是因为它们本来就被设计为可与任何OleDb或ODBC兼容的数据库工作，但它们的具体实现是在专门为它们设计的特定的.NET数据提供程序中的。这可以从图1-5中看出。注意你的程序可以使用图1-5中灰色框内部的任何对象。你可以用非连接对象、数据适配器（data adapter）、连接对象或它们的联合体来构建你的应用程序。

图1-5  完整的模型：应用程序、ADO.NET、多个数据源以及多个数据提供程序

现在稍微考虑一下，比较图1-5和图1-1中的不同之处。图1-5的阴影块表示了图1-1中间块的放大图。

通常，.NET框架自带的提供程序可以在System.Data命名空间下找到其自己的命名空间。表1-1是.NET 2.0框架自带的一些通用的数据提供程序的列表。

表1-1  多个.NET数据提供程序

正如你从表1-1中得知的，微软SQL Server 7.0和Oracle 8.1.6也可以用ODBC或OleDb数据提供程序访问。使用特定数据源的数据提供程序，诸如SqlClient或OracleClient等，会比使用通用数据提供程序更具一些独特的优势：

l 特定数据提供程序，比如SqlClient或OracleClient，具有比通用数据提供程序更高的性能。

l 特定数据提供程序可以更好地配置数据库特定的功能。

l 特定数据提供程序能处理数据库特定的数据类型。在很多情况下这样处理可以免除装箱/拆箱（boxing/unboxing）操作的开销，而且能减少数据类型精确度的错误，这样的错误通常会在把Int64保存到Int32的列时不经意地发生。

然而，在很多情况下，你可能并不知道需要与ADO.NET交互的确切数据源，而ADO.NET就为你在编写与提供程序无关的代码时提供了多种选择。特别地，ADO.NET 1.1为你提供了两种编写与提供程序无关的代码的方法：

l 使用非特定数据提供程序：你可以坚持使用对所有数据源都是通用（common）的最小化的功能，或者使用ODBC或OleDb数据提供程序。这些数据提供程序会有性能问题、功能受损或其他缺陷，因为它们不是数据库特定的。然而，它们有一个优势：可以编写独立于数据库的代码。根据你真正的需求，你可以忽略性能或功能设置问题，并且坚持用一个通用的.NET数据提供程序。

l 使用接口和基类：ADO.NET为大多数普遍需要用到的对象提供了标准接口和基类。比如，System.Data.SqlClient.SqlConnection对象必定实现了System.Data.IDbConnection，而且从System.Data.Providerbase.DbConnectionBase继承而来。使用由父接口或已实现的接口所表示的数据类型，你就可以避免出现运行时类型转换的错误。这种方法的缺点是你还需要坚持使用通用的最小化的功能，即使现在使用ODBC或OleDb数据提供程序时所遇到的性能上的差异并没有多大。

这两种方法并不是最好的。第一种方法不是很好用，第二种方法需要提供一个子集，而且在大多数情况下，是一个与特定数据源提供程序不同的功能集。为了解决这些问题，ADO.NET 2.0提供了一个提供程序工厂（provider factory），在这个工厂中，只要你知道正确的提供程序名称（该名称可以是字符串变量），就可以实例化可用的提供程序。这也被称为ProviderBase模型。

1.4.1  使用ProviderBase模型

这个方法接合了上面两种方法的优势。任何一台具有Windows操作系统的机器都可能安装了多个数据提供程序。在.NET 2.0框架中，Machine.Config文件中有一个配置部分名为DbProvider- Factories。在这个配置部分中，你能定义各种可以通过ProviderBase模型访问的数据提供程序。代码清单1-1显示了一个典型的Machine.Config文件的DbProviderFactories配置部分。

代码清单1-1  DbProviderFactories配置部分

你可以使用代码清单1-2和代码清单1-3中的代码来列举计算机上所支持的所有提供程序。

代码清单1-2  列举所有可用的提供程序（C#代码）

代码清单1-3  列举所有可用的提供程序（Visual Basic.NET代码）

这段代码运行时就会产生如下的输出：

如果你真的想用这些数据提供程序中的一个，那么就可以通过代码清单1-4和代码清单1-5来实现。

代码清单1-4  使用ProviderBase模型（C#代码）

代码清单1-5  使用ProviderBase模型（Visual Basic.NET代码）

在代码清单1-4和代码清单1-5中，要注意的是ProviderBase模型可以让你获取强类型的特定提供程序对象，比如SqlConnection和SqlCommand，而不必事先知道用户需要使用哪个提供程序。用户可以通过用户界面上的下拉框选择“System.Data.SqlClient”，该选项只是简单地作为字符串参数传递给GetFactory方法。

这是可以实现的，因为DbProviderFactory对象总是返回这样一些数据类型对象：这些对象实际上是.NET数据提供程序中的各种公共对象的基类。这些公共的基类对象包含在System.Data.Common命名空间下，可以被其他任何类继承以便创建第三方的.NET数据提供程序。

1.4.2  第三方.NET数据提供程序

ADO.NET包含各种基类和接口，可供各种第三方.NET数据提供程序导出或实现，以便创建这些提供程序各自对一些通用对象的特定实现。这些通用对象有Connection、Command等。一个这样的例子就是DbDataAdapter类，该类实现了IDbDataAdapter接口。因此，在System.Data.SqlClient命名空间下的SqlDataAdapter是从DbDataAdapter导出而来的，因而也就实现了IDbDataAdapter接口。这个命名空间下最重要的类如表1-2所示。

表1-2  System.Data.Common命名空间下主要的类

（续）