ADO.NET提供了一个统一的编程模式和一组公用的类来进行任何类型的数据访问，而不管你用何种语言来开发代码。ADO.NET是全新的，但又与ADO尽可能保持一致，它使编程模式从一个客户端/服务器、基于连接的模式转变到了一个新的模式，这个新模式可以让断开的前端下载记录、离线工作、然后重新连接来提交变化。ADO.NET是WinForms应用程序、ASP.NET应用程序和Web services的一个共有的特点。其功能可以跨LAN和Internet连接来实现，可以在有状态（stateful）和无状态（stateless）情况下实现。

这就意味着，作为一个共有的技术，ADO.NET的对象在所有可能的环境中并不是同等强大的。用ADO.NET为一个富客户端（rich client）构建一个数据层同为一个客户端通常是共享的和重要的实体（如Web服务器）的Web应用程序构建一个数据层并不一样。

如果你从前是个ADO开发人员，现在已经用ADO.NET了，那么你可能把数据访问看做是一个万能的对象，如Recordset。我们很自然地会将旧的对象模式同新的对象模式匹配起来，并将现有的方法用于.NET应用程序。然而，在ADO环境中的某些好的方法在转换到ADO.NET环境时就可能并不强大了。而且，看起来很微不足道的ADO.NET对象模式的复杂性可能会导致很糟糕的编程情况、不理想的代码、甚至是功能不能实现。我将讲述在ADO.NET编程中可能会给你带来麻烦的10个方面，并提供技巧和解决方法来避免它们。

1. 避免Database-Agnostic形式的编程
ADO.NET中的数据访问是强类型的，就是说在任何时候你都必须了解你正在处理的是什么数据源（data source)。相反，在ADO中，你可以编写数据访问代码（它们充分利用了OLE DB提供者的通用模式），并将基本的数据源只看做是个参数。ADO对象模式提供了唯一的连接和命令对象，它们隐藏了基本的DBMS的特征。一旦你在Connection对象上设置了Provider属性，那么为SQL Server或Oracle创建一个命令对象就需要同样的代码。许多开发人员都通过该功能来使用生产环境外的Access数据库，以便很快地测试或演示应用程序。

在ADO.NET中是不能这么做的，因为在ADO.NET中，至少连接对象必须是特定于数据源的。你不能以一种间接或通用的方式来创建连接，除非你决定运用ADO的数据访问技术——OLE DB。在ADO.NET中，你可以用OleDbConnection类创建到一个数据库的连接，这个类可以让你访问各种数据源。在.NET托管环境中运用System.Data.OleDb名字空间中的类并不特别有效，因为它们是用OLE DB来访问数据的。你只能用OLE DB来访问那些没有.NET数据提供者的数据源。

如果你的应用程序必须访问全异的数据源（而且你知道可能涉及什么数据源——一个合理的假设），那么你可以创建一个集中的factory类，它返回一个连接对象，并通过一个通用的接口（IDbConnection接口）来管理这个连接对象。Factory类在内部运用应用程序参数来决定使用什么.NET数据提供者：' Create the connection
Dim factory As New MyAppConnectionFactory
Dim conn As IDbConnection
conn = factory.CreateConnection(connString)

' Create the command
Dim cmd As IDbCommand = conn.CreateCommand(query)




一旦你得到了一个连接对象，你就可以以database-agnostic的方式来创建和执行一个命令了，而不管使用的数据源是什么。你可以使用CreateCommand方法并通过IDbCommand接口来引用命令。然后，你可以用IDbCommand接口上的ExecuteReader方法或ExecuteNonQuery方法来执行命令。如果你用ExecuteReader，你就可以得到一个data reader并可以用IDataReader接口来对它进行一般的访问了。

你不能用一个通用的数据库编程模式来填充一个DataSet对象。实际上，你不能像创建一个命令那样以一种间接的方式来创建data adapter对象。原因就是，在有些情况下，data adapter不同于命令对象，它可以在内部隐含地创建一个连接。然而，它必须以一种强类型的方式工作，而且必须知道基本的数据库服务器是什么。

2. 运用字符串来串行化扩展的属性
几个ADO.NET对象都拥有一个叫做ExtendedProperties的集合。该属性就像收集货物（cargo collection）一样，可以用来存储任何类型的用户信息。DataSet、DataTable和DataColumn就是可以提供该数据成员的类。ADO.NET通过运用PropertyCollection类封装的一个哈希表来实现这个ExtendedProperties属性。你可以用Add方法将数据插入到集合中。Add方法使用了两个参数来保存数据——key和value。该方法的原形将参数定义为通用的对象类型，你可以存储任何类型的信息。然而，在特殊情况下，你应该特别注意那些被保存为扩展属性的对象的类型。

如果你想将包含扩展属性的ADO.NET对象串行化到XML，最好只用字符串。如果不行，你必须对ADO.NET的内在的serializer的行为采取对策。

当ADO.NET将一个DataSet对象保存到XML时，ExtendedProperties集合的内容就被串行化到内存中了，但大概是出于性能的原因，ADO.NET运用了ToString方法，而不是XML serializer来实现串行化。更重要的是，当ADO.NET对象被读回并复原时，ExtendedProperties集合包含的是对象的字符串表现形式，而不是对象本身。

3. 运用具有BLOB字段的ExecuteXmlReader
用于SQL Server的.NET数据提供者（data provider）使用了数据库提供的XML扩展名，并提供了一个额外的方法（ExecuteXmlReader）来执行查询。命令对象上的所有的执行者（例如ExecuteReader和ExecuteScaler）都采用不同的方法来得到结果集。ExcecuteReader通过一个托管指针（managed cursor）（data reader）来返回数据，而ExecuteScaler返回结果集中的第一个值，把它作为一个标量值。ExecuteXmlReader执行查询，并返回已经绑定到一个XmlTextReader对象的基于XML的输出流。通过这种方式，你就不需要做额外的工作来以XML的方式加工数据了。要实现这一点，查询字符串必须返回XML数据。对SQL Server来说，当查询字符串包含一个FOR XML子句时，就可以实现它。尽管这只是一种可能。

一个不太为人所知的情况是，要使ExecuteXmlReader工作，让结果集包含XML数据就足够了。 下面的查询方法很好，只要列包含XML格式的文本就行：SELECT data FROM table WHERE key=1

这个列是个典型的BLOB或ntext字段，其文本显示为XML。简要地看看ExecuteXmlReader方法的内部结构会有助于我们的理解。该方法用ExecuteReader来执行查询，并从数据提供者得到一个数据流对象。接下来，它将数据流绑定到XmlTextReader类的一个新创建的实例上，这个实例被返回给调用者。连接一直处于忙碌状态，直到XML reader停止工作。SQL Server提供者是唯一的提供者，它提供了方法让我们从一个XML reader直接读取数据，但这种做法更多的是与提供者有关，而与数据库性能的关系并不大。Oracle支持XML查询，但Oracle的数据提供者并不支持XML查询。相比之下，为OLE DB数据提供者编写一个ExecuteXmlReader方法并不难（点此下载实例）。

4. 不要设法缓存一个DataView
DataSet和DataTable对象是唯一的包含数据的ADO.NET对象。DataView是一个不能串行化的、轻量级的类，它只代表构建在一个表上的视图（view）。你可以根据一个表达式或行的状态来过滤视图。许多应用程序都需要你管理数据视图并将它们绑定到数据控件上，如Windows和Web DataGrid控件。一个DataView对象不能缓存数据；它只是缓存了与当前过滤器相匹配的基本的表中的行的索引。缓存索引的顺序与当前的排序表达式一致。缓存DataView而不缓存基本的DataTable是不行的。

例如，提供分页（比如通过运用DataGrid控件）的ASP.NET应用程序通常以一个DataView对象结尾，因为它支持排序和过滤。在有些情况下（大多是基于性能的原因），你可能决定要缓存数据