Dennis Lu Doug Rothaus 数据库 数据访问技术 3 具备使用ADO.NET和.NET框架开发经验的人员 ADO.NET作为微软最新的数据访问技术，已经在企业开发中得到了广泛的应用。对于一线的开发人员来说，掌握基本的概念和技术之后，提高应用水平和解决实际问题的最有效手段，莫过于相互交流彼此的最佳时间经验经验。在这篇文章中，两位ADO.NET专家向读者毫无保留地、详尽地介绍了很多实用经验。 本文为您提供了在Microsoft ADO.NET应用程序中实现和获得最佳性能、可伸缩性以及功能的最佳解决方案；同时也讲述了使用ADO.NET中可用对象的最佳实践；并提出一些有助于优化ADO.NET应用程序设计的建议。 本文包括 有关.NET框架所包含的.NET框架数据提供程序的信息。 DataSet和DataReader之间的比较，以及这些对象中每个对象最佳用法的解释。 解释如何使用DataSet、Commands和Connections。 有关与XML集成的信息。 通用的技巧与问题。 .NET框架中的数据提供程序（Data Provider）在应用程序和数据源之间起到桥梁作用。.NET框架数据提供程序能够从数据源中返回查询结果、对数据源执行命令、将DataSet中的更改传播给数据源。本文包括有关哪个.NET框架数据提供程序是最适合您需要的一些技巧。 为了使您的应用程序获得最佳性能，请使用最适合您的数据源的.NET框架数据提供程序。有许多数据提供程序可供您的应用程序选用。下表（见下页）提供了关于可用数据提供程序的信息，以及每个数据提供程序最适合哪个数据源。 为了在连接到Microsoft SQL Server 7.0或更高版本时获得最佳性能，请使用SQL Server .NET数据提供程序。SQL Server .NET数据提供程序的设计目的就在于不通过任何附加技术层就可以直接访问SQL Server。图1说明了可用于访问SQL Server 7.0或更高版本的不同技术之间的区别。 ODBC .NET数据提供程序可在Microsoft.Data.ODBC命名空间中找到，它的体系结构与用于SQL Server和OLE DB的.NET数据提供程序相同。ODBC .NET数据提供程序遵循命名约定-以“ODBC”为前缀（例如，OdbcConnection），并使用标准ODBC连接字符串。 ADO.NET提供以下两个对象，用于检索关系数据并将其存储在内存中：DataSet和DataReader。DataSet提供一个内存中数据的关系表示形式，一整套包括一些表在内的数据（这些表包含数据、对数据进行排序并约束数据），以及表之间的关系。DataReader提供一个来自数据库的快速、仅向前、只读数据流。 当使用DataSet时，经常会利用DataAdapter（也可能是CommandBuilder）与数据源进行交互。当使用DataSet时，也可以利用DataView对DataSet中的数据应用排序和筛选。也可以从DataSet继承，创建强类型DataSet，用于将表、行和列作为强类型对象属性公开。 下列主题包括的信息涉及：使用DataSet或DataReader的最佳时机、如何优化访问它们所包含数据、以及如何优化使用DataAdapter（包括CommandBuilder）和DataView的技巧。 当设计应用程序时，要考虑应用程序所需功能的等级，以确定使用DataSet或者是DataReader。 要通过应用程序执行以下操作，就要使用DataSet： 在结果的多个离散表之间进行导航。 操作来自多个数据源（例如，来自多个数据库、一个XML文件和一个电子表格的混合数据）的数据。 在各层之间交换数据或使用XML Web服务。与DataReader不同的是，DataSet能传递给远程客户端。 重用同样的记录集合，以便通过缓存获得性能改善（例如排序、搜索或筛选数据）。 每条记录都需要执行大量处理。对使用DataReader返回的每一行进行扩展处理会延长服务于DataReader的连接的必要时间，这影响了性能。 使用XML操作对数据进行操作，例如可扩展样式表语言转换（XSLT转换）或XPath查询。 对于下列情况，要在应用程序中使用DataReader： 不需要缓存数据。 要处理的结果集太大，内存中放不下。 一旦需要以仅向前、只读方式快速访问数据。 注填充DataSet时，DataAdapter使用DataReader。因此，使用DataAdapter取代DataSet提升的性能表现为节省了DataSet占用内存和填充DataSet需要的循环。一般来说，此性能提升只是象征性的，因此，设计决策应以所需功能为基础。 DataSet的另一个好处是可被继承以创建一个强类型DataSet。强类型DataSet的好处包括设计时类型检查，以及Microsoft Visual Studio.NET用于强类型DataSet语句结束所带来的好处。修改了DataSet的架构或关系结构后，就可以创建一个强类型DataSet，将行和列作为对象的属性公开，而不是作为集合中的项公开。例如，不公开客户表中行的姓名列，而公开Customer对象的Name属性。类型化DataSet从DataSet类派生，因此不会牺牲DataSet的任何功能。也就是说，类型化DataSet仍能远程访问，并作为数据绑定控件（例如DataGrid）的数据源提供。如果架构事先不可知，仍能受益于通用DataSet的功能，但却不能受益于强类型DataSet的附加功能。 使用强类型DataSet时，可以使用DataSet的XML架构定义语言(XSD)架构来确保强类型DataSet可以正确处理空引用。nullValue标识符使您可用一个指定的值String.Empty代替DBNull、保留空引用或引发异常。选择哪个选项取决于应用程序的上下文。默认情况下，如果遇到空引用，就会引发异常。 如果想用服务器上的更新值刷新DataSet中的值，就使用DataAdapter.Fill。如果有在DataTable上定义的主键，DataAdapter.Fill会根据主键进行新行匹配，并且当更改到现有行时应用服务器上的值。即使刷新之前修改了这些数据，刷新行的RowState仍被设置为Unchanged。注意，如果没有为DataTable定义主键，DataAdapter.Fill就用可能重复的主键值添加新行。 如果想用来自服务器的当前值刷新表，并同时保留对表中的行所做的任何更改，必须首先用DataAdapter.Fill填充表，并填充一个新的DataTable，然后用preserveChanges值true将DataTable合并到DataSet之中。 在DataSet中查询与特定条件相匹配的行时，可以利用基于索引的查找提高搜索性能。当将PrimaryKey值赋给DataTable时，会创建一个索引。当给DataTable创建DataView时，也会创建一个索引。下面是一些利用基于索引进行查找的技巧。 如果对组成DataTable的PrimaryKey的列进行查询，要使用DataTable.Rows.Find而不是DataTable.Select。 对于涉及到非主键列的查询，可以使用DataView为数据的多个查询提高性能。当将排序顺序应用到DataView时，就会建立一个搜索时使用的索引。DataView公开Find和FindRows方法，以便查询基础DataTable中的数据。 如果不需要表的排序视图，仍可以通过为DataTable创建DataView来利用基于索引的查找。注意，只有对数据执行多个查询操作时，这样才会带来好处。如果只执行单一查询，创建索引所需要的处理就会降低使用索引所带来的性能提升。 如果创建了DataView，并且修改了Sort、RowFilter或RowStateFilter属性，DataView就会为基础DataTable中的数据建立索引。创建DataView对象时，要使用DataView构造函数，它用Sort、RowFilter和RowStateFilter值作为构造函数参数（与基础DataTable一起）。结果是创建了一次索引。创建一个“空”DataView并随后设置Sort、RowFilter或RowStateFilter属性，会导致索引至少创建两次。 ADO.NET可以显式控制从数据源中返回什么样的数据，以及在DataSet中本地缓存多少数据。对查询结果的分页没有唯一的答案，但下面有一些设计应用程序时应该考虑的技巧。 避免使用带有startRecord和maxRecords值的DataAdapter.Fill重载。当以这种方式填充DataSet时，只有maxRecords参数（从startRecord参数标识的记录开始）指定的记录数量用于填充DataSet，但无论如何总是返回完整的查询。这就会引起不必要的处理，用于读取“不需要的”记录；而且为了返回附加记录，会耗尽不必要的服务器资源。 用于每次只返回一页记录的技术是创建SQL语句，将WHERE子句以及ORDER BY子句和TOP谓词组合起来。此技术取决于存在一种可唯一标识每一行的办法。当浏览下一页记录时，修改WHERE子句使之包含所有唯一标识符大于当前页最后一个唯一标识符的记录。当浏览上一页记录时，修改WHERE子句使之返回所有唯一标识符小于当前页第一个唯一标识符的记录。两种查询都只返回记录的TOP页。当浏览上一页时，需要以降序为结果排序。这将有效地返回查询的最后一页（如果需要，显示之前也许要重新排序结果）。 另一项每次只返回一页记录的技术是创建SQL语句，将TOP谓词和嵌入式SELECT语句的使用结合在一起。此技术并不依赖于存在一种可唯一标识每一行的办法。使用这项技术的第一步是将所需页的数量与页大小相乘。然后将结果传递给SQL Query的TOP谓词，该查询以升序排列。再将此查询嵌入到另一个查询中，后者从降序排列的嵌入式查询结果中选择TOP页大小。实质上，返回的是嵌入式查询的最后一页。例如，要返回查询结果的第三页（页大小是10），应该书写如下所示的命令： SELECT TOP 10 * FROM (SELECT TOP 30 * FROM Customers ORDER BY Id ASC) AS Table1 ORDER BY Id DESC 注意：从查询中返回的结果页以降序显示。如果需要，应该重新排序。 如果数据不经常变动，可以在DataSet中本地维护一个记录缓存，以此提高性能。例如，可以在本地DataSet中存储10页有用的数据，并且只有当用户浏览超出缓存第一页和最后一页时，才从数据源中查询新数据。 当用数据填充DataSet时，DataAdapter.Fill方法使用DataSet的现有架构，并使用从SelectCommand返回的数据填充它。如果在DataSet中没有表名与要被填充的表名相匹配，Fill方法就会创建一个表。默认情况下，Fill仅定义列和列类型。 通过设置DataAdapter的MissingSchemaAction属性，可以重写Fill的默认行为。例如，要让Fill创建一个表架构，并且还包括主键信息、唯一约束、列属性、是否允许为空、最大列长度、只读列和自动增量的列，就要将DataAdapter.MissingSchemaAction指定为MissingSchemaAction.AddWithKey。或者，在调用DataAdapter.Fill前，可以调用DataAdapter.FillSchema来确保当填充DataSet时架构已到位。 对FillSchema的调用会产生一个到服务器的额外行程，用于检索附加架构信息。为了获得最佳性能，需要在调用Fill之前指定DataSet的架构，或者设置DataAdapter的MissingSchemaAction。 假设SelectCommand执行单一表SELECT，CommandBuilder就会以DataAdapter的SelectCommand属性为基础自动生成DataAdapter的InsertCommand、UpdateCommand、和DeleteCommand属性。下面是为获得最佳性能而使用CommandBuilder的一些技巧。 CommandBuilder的使用应该限制在设计时或即席方案中。生成DataAdapter命令属性所必需的处理会影响性能。如果预先知道INSERT/UPDATE/DELETE语句的内容，就显式设置它们。一个比较好的设计技巧是，为INSERT/UPDATE/DELETE命令创建存储过程并显式配置DataAdapter命令属性以使用它们。 CommandBuilder使用DataAdapter的SelectCommand属性确定其他命令属性的值。如果DataAdapter的SelectCommand本身曾经更改过，确保调用RefreshSchema以更新命令属性。 如果DataAdapter命令属性为空（命令属性默认情况下为空），CommandBuilder仅仅为它生成一条命令。如果显式设置了命令属性，CommandBuilder不会重写它。如果希望CommandBuilder为以前已经设置过的命令属性生成命令，就将命令属性设置为空。 很多数据库支持将多条命令合并或批处理成一条单一命令执行。例如，SQL Server使您可以用分号“;”分隔命令。将多条命令合并成单一命令，能减少到服务器的行程数，并提高应用程序的性能。例如，可以将所有预定的删除在应用程序中本地存储起来，然后再发出一条批处理命令调用，从数据源删除它们。 虽然这样做确实能提高性能，但是，当对DataSet中的数据更新进行管理时，可能会增加应用程序的复杂性。要保持简单，可能要在DataSet中为每个DataTable创建一个DataAdapter。 如果使用批处理SQL语句检索多个表并填充DataSet，第一个表用指定给Fill方法的表名命名。后面的表用指定给Fill方法的表名加上一个从1开始并且增量为1的数字命名。例如，如果运行下面的代码： 'Visual Basic Dim da As SqlDataAdapter = New SqlDataAdapter( "SELECT * FROM Customers; SELECT * FROM Orders;", myConnection) Dim ds As DataSet = New DataSet() da.Fill(ds, "Customers") //C# SqlDataAdapter da = new SqlDataAdapter( "SELECT * FROM Customers; SELECT * FROM Orders;", myConnection); DataSet ds = new DataSet(); da.Fill(ds, "Customers"); 来自Customers表的数据放在名为“Customers”的DataTable中。来自Orders表的数据放在名为“Customers1”的DataTable中。 填充完DataSet之后，可以很容易地将“Customers1”表的TableName属性改为“Orders”。但是，后面的填充会导致“Customers”表被重新填充，而“Orders”表会被忽略，并创建另外一个“Customers1”表。为了对这种情况作出补救，创建一个DataTableMapping，将“Customers1”映射到“Orders”，并为其他后面的表创建其他的表映射。例如： 'Visual Basic Dim da As SqlDataAdapter = New SqlDataAdapter( "SELECT * FROM Customers; SELECT * FROM Orders;", myConnection) da.TableMappings.Add("Customers1", "Orders") Dim ds As DataSet = New DataSet() da.Fill(ds, "Customers") //C# SqlDataAdapter da = new SqlDataAdapter( "SELECT * FROM Customers; SELECT * FROM Orders;", myConnection); da.TableMappings.Add("Customers1", "Orders"); DataSet ds = new DataSet(); da.Fill(ds, "Customers"); 下面是一些使用DataReader获得最佳性能的技巧，同时还回答了一些关于使用DataReader的常见问题。 在访问相关Command的任何输出参数之前，必须关闭DataReader。 完成读数据之后总是要关闭DataReader。如果使用Connection只是用于返回DataReader，那么关闭DataReader之后立刻关闭它。 另外一个显式关闭Connection的方法是将CommandBehavior.CloseConnection传递给ExecuteReader方法，以确保相关的连接在关闭DataReader时被关闭。如果从一个方法返回DataReader，而且不能控制DataReader或相关连接的关闭，则这样做特别有用。 不能在层之间远程访问DataReader。DataReader是为已连接好的数据访问设计的。 当访问列数据时，使用类型化访问器，例如，GetString、GetInt32等。这使您不用进行将GetValue返回的Object强制转换成特定类型所需的处理。 一个单一连接每次只能打开一个DataReader。在ADO中，如果打开一个单一连接，并且请求两个使用只进、只读游标的记录集，那么ADO会在游标生存期内隐式打开第二个、未池化的到数据存储区的连接，然后再隐式关闭该连接。对于ADO.NET，“秘密”完成的动作很少。如果想在相同的数据存储区上同时打开两个DataReaders，就必须显式创建两个连接，每个DataReader一个。这是ADO.NET为池化连接的使用提供更多控制的一种方法。 默认情况下，DataReader每次Read时都要将整行加载到内存。这允许在当前行内随机访问列。如果不需要这种随机访问，为了提高性能，就将CommandBehavior.SequentialAccess传递给ExecuteReader调用。这将DataReader的默认行为更改为仅在请求时将数据加载到内存。注意，CommandBehavior.SequentialAccess要求顺序访问返回的列。也就是说，一旦读过返回的列，就不能再读它的值了。 如果已经完成读取来自DataReader的数据，但仍然有大量挂起的未读结果，就在调用DataReader的Close之前先调用Command的Cancel。调用DataReader的Close会导致在关闭游标之前检索挂起的结果并清空流。调用Command的Cancel会放弃服务器上的结果，这样，DataReader在关闭的时候就不必读这些结果。如果要从Command返回输出参数，还要调用Cancel放弃它们。如果需要读取任何输出参数，不要调用Command的Cancel，只要调用DataReader的Close即可。 用DataReader检索二进制大对象(BLOB)时，应该将CommandBehavior.SequentialAccess传递给ExecuteReader方法调用。因为DataReader的默认行为是每次Read都将整行加载到内存，又因为BLOB值可能非常大，所以结果可能由于单个BLOB而使大量内存被用光。SequentialAccess将DataReader的行为设置为只加载请求的数据。然后还可以使用GetBytes或GetChars控制每次加载多少数据。 记住，使用SequentialAccess时，不能不按顺序访问DataReader返回的不同字段。也就是说，如果查询返回三列，其中第三列是BLOB，并且想访问前两列中的数据，就必须在访问BLOB数据之前先访问第一列的值，然后访问第二列的值。这是因为现在数据是顺序返回的，并且DataReader一旦读过该数据，该数据就不再可用。 ADO.NET提供了几种命令执行的不同方法以及优化命令执行的不同选项。下面包括一些技巧，它们是关于选择最佳命令执行以及如何提高执行命令的性能。 不同.NET框架数据提供程序之间的命令执行被尽可能标准化了。但是，数据提供程序之间仍然存在差异。下面给出一些技巧，可微调用于OLE DB的.NET框架数据提供程序的命令执行。 按照ODBC CALL语法使用CommandType.Text调用存储过程。使用CommandType.StoredProcedure只是秘密地生成ODBC CALL语法。 一定要设置OleDbParameter的类型、大小（如果适用）、以及精度和范围（如果参数类型是numeric或decimal）。注意，如果不显式提供参数信息，OleDbCommand会为每个执行命令重新创建OLE DB参数访问器。 使用SqlCommand执行存储过程的快速提示：如果调用存储过程，将SqlCommand的CommandType属性指定为StoredProcedure的CommandType。这样通过将该命令显式标识为存储过程，就不需要在执行之前分析命令。 对于重复作用于数据源的参数化命令，Command.Prepare方法能提高性能。Prepare指示数据源为多次调用优化指定的命令。要想有效利用Prepare，需要彻底理解数据源是如何响应Prepare调用的。对于一些数据源（例如SQL Server 2000），命令是隐式优化的，不必调用Prepare。对于其他（例如SQL Server 7.0）数据源，Prepare会比较有效。 只要用户没有指定元数据信息，ADO.NET的许多对象就会推断元数据信息。下面是一些示例： DataAdapter.Fill方法，如果DataSet中没有表和列，DataAdapter.Fill方法会在DataSet中创建表和列。 CommandBuilder，它会为单表SELECT命令生成DataAdapter命令属性。 CommandBuilder.DeriveParameters，它会填充Command对象的Parameters集合。 但是，每次用到这些特性，都会有性能损失。建议将这些特性主要用于设计时和即席应用程序中。在可能的情况下，显式指定架构和元数据。其中包括在DataSet中定义表和列、定义DataAdapter的Command属性、以及为Command定义Parameter信息。 如果想返回像Count(*)、Sum(Price)或Avg(Quantity)的结果那样的单值，可以使用Command.ExecuteScalar。ExecuteScalar返回第一行第一列的值，将结果集作为标量值返回。因为单独一步就能完成，所以ExecuteScalar不仅简化了代码，还提高了性能；要是使用DataReader就需要两步才能完成（即，ExecuteReader+取值）。 使用不返回行的SQL语句时，例如修改数据（例如INSERT、UPDATE或DELETE）或仅返回输出参数或返回值，请使用ExecuteNonQuery。这避免了用于创建空DataReader的任何不必要处理。 如果表（在数据库中）中的列允许为空，就不能测试参数值是否“等于”空。相反，需要写一个WHERE子句，测试列和参数是否都为空。下面的SQL语句返回一些行，它们的LastName列等于赋给@LastName参数的值，或者LastName列和@LastName参数都为空。 SELECT * FROM Customers WHERE ((LastName = @LastName) OR (LastName IS NULL AND @LastName IS NULL)) 对数据库的命令中，当将空值作为参数值发送时，不能使用null（Visual Basic .NET中为Nothing）。而需要使用DBNull.Value。例如： 'Visual Basic Dim param As SqlParameter = New SqlParameter("@Name", SqlDbType.NVarChar, 20) param.Value = DBNull.Value //C# SqlParameter param = new SqlParameter("@Name", SqlDbType.NVarChar, 20); param.Value = DBNull.Value; ADO.NET的事务模型已经更改。在ADO中，当调用StartTransaction时，调用之后的任何更新操作都被视为是事务的一部分。但是，在ADO.NET中，当调用Connection .BeginTransaction时，会返回一个Transaction对象，需要将它与Command的Transaction属性联系起来。这种设计可以在一个单一连接上执行多个根事务。如果未将Command.Transaction属性设置为一个针对相关的Connection而启动的Transaction，那么Command就会失败并引发异常。 即将发布的.NET框架将使您可以在现有的分布式事务中手动登记。这对于对象池方案来说很理想；在该方案中，一个池对象打开一次连接，但是在多个独立的事务中都涉及到该对象。.NET框架1.0发行版中这一功能并不可用。 高性能应用程序与使用中的数据源保持最短时间的连接，并且利用性能增强技术，例如连接池。下面的主题提供一些技巧，有助于在使用ADO.NET连接到数据源时获得更好的性能。 用于ODBC的SQL Server、OLE DB和.NET框架数据提供程序隐式缓冲连接。通过在连接字符串中指定不同的属性值，可以控制连接池的行为。 DataAdapter的Fill和Update方法在连接关闭的情况下自动打开为相关命令属性指定的连接。如果Fill或Update方法打开了连接，Fill或Update将在操作完成的时候关闭它。为了获得最佳性能，仅在需要时将与数据库的连接保持为打开。同时，减少打开和关闭多操作连接的次数。 如果只执行单个的Fill或Update方法调用，建议允许Fill或Update方法隐式打开和关闭连接。如果对Fill和Update调用有很多，建议显式打开连接，调用Fill和Update，然后显式关闭连接。 另外，当执行事务时，显式地在开始事务之前打开连接，并在提交之后关闭连接。例如： 'Visual Basic Public Sub RunSqlTransaction( da As SqlDataAdapter, myConnection As SqlConnection, ds As DataSet) myConnection.Open() Dim myTrans As SqlTransaction = myConnection.BeginTransaction() myCommand.Transaction = myTrans Try da.Update(ds) myTrans.Commit() Console.WriteLine("Update successful.") Catch e As Exception Try myTrans.Rollback() Catch ex As SqlException If Not myTrans.Connection Is Nothing Then Console.WriteLine( "An exception of type " ' ex.GetType().ToString() ' " was encountered while attempting to roll back the transaction." ) End If End Try Console.WriteLine( "An exception of type " ' e.GetType().ToString() ' " was encountered.") Console.WriteLine("Update failed.") End Try myConnection.Close() End Sub //C# public void RunSqlTransaction( SqlDataAdapter da, SqlConnection myConnection, DataSet ds) { myConnection.Open(); SqlTransaction myTrans = myConnection.BeginTransaction(); myCommand.Transaction = myTrans; try { da.Update(ds); myCommand.Transaction.Commit(); Console.WriteLine("Update successful."); } catch(Exception e) { try { myTrans.Rollback(); } catch (SqlException ex) { if (myTrans.Connection != null) { Console.WriteLine( "An exception of type " + ex.GetType() + " was encountered while attempting to roll back the transaction." ); } } Console.WriteLine(e.ToString()); Console.WriteLine("Update failed."); } myConnection.Close(); } 完成对Connection或DataReader对象的使用后，总是显式地关闭它们。尽管垃圾回收最终会清除对象并因此释放连接和其他托管资源，但垃圾回收仅在需要时执行。因此，确保任何宝贵的资源被显式释放仍然是您的责任。并且，没有显式关闭的Connections可能不会返回到池中。例如，一个超出作用范围却没有显式关闭的连接，只有当连接池大小达到最大并且连接仍然有效时，才会被返回到连接池中。 注不要在类的Finalize方法中对Connection、DataReader或任何其他托管对象调用Close或Dispose。最后完成的时候，仅释放类自己直接拥有的非托管资源。如果类没有任何非托管资源，就不要在类定义中包含Finalize方法。 对于C#程序员来说，确保始终关闭Connection和DataReader对象的一个方便的方法就是使用using语句。using语句在离开自己的作用范围时，会自动调用被“使用”的对象的Dispose。例如： //C# string connString = "Data Source=localhost;Integrated Security=SSPI;Initial Catalog=Northwind;"; using (SqlConnection conn = new SqlConnection(connString)) { SqlCommand cmd = conn.CreateCommand(); cmd.CommandText = "SELECT CustomerId, CompanyName FROM Customers"; conn.Open(); using (SqlDataReader dr = cmd.ExecuteReader()) { while (dr.Read()) Console.WriteLine("{0}\t{1}", dr.GetString(0), dr.GetString(1)); } } Using语句不能用于Microsoft Visual Basic .NET。 如果连接已经打开，OleDbConnection.State属性会对DBPROP_CONNECTIONSTATUS属性的DATASOURCEINFO属性集执行本地OLE DB调用IDBProperties.GetProperties，这可能会导致对数据源的往返行程。也就是说，检查State属性的代价可能很高。所以仅在需要时检查State属性。如果需要经常检查该属性，监听OleDbConnection的StateChange事件可能会使应用程序的性能好一些。 ADO.NET在DataSet中提供了广泛的XML集成，并公开了SQL Server 2000及其更高版本提供的部分XML功能。还可以使用SQLXML 3.0广泛地访问SQL Server 2000及其更高版本中的XML功能。下面是使用XML和ADO.NET的技巧和信息。 DataSet与XML紧密集成，并提供如下功能： 从XSD架构中加载DataSet的架构或关系型结构。 从XML加载DataSet的内容。 如果没有提供架构，可以从XML文档的内容推断出DataSet的架构。 将DataSet的架构写为XSD架构。 将DataSet的内容写为XML。 同步访问使用DataSet的数据的关系表示，以及使用XmlDataDocument的数据的层次表示。 注可以使用这种同步将XML功能（例如，XPath查询和XSLT转换）应用到DataSet中的数据，或者在保留原始XML保真度的前提下为XML文档中数据的全部或其中一个子集提供关系视图。 从XML文件加载DataSet时，可以从XSD架构加载DataSet架构，或者在加载数据前预定义表和列。如果没有可用的XSD架构，而且不知道为XML文件的内容定义哪些表和列，就可以在XML文档结构的基础上对架构进行推断。 架构推断作为迁移工具很有用，但应只限于设计阶段应用程序，这是由于推断处理有如下限制。 对架构的推断会引入影响应用程序性能的附加处理。 所有推断列的类型都是字符串。 推断处理不具有确定性。也就是说，它是基于XML文件内容的，而不是预定的架构。因此，对于两个预定架构相同的XML文件，由于它们的内容不同，结果得到两个完全不同的推断架构。 如果正从SQL Server 2000 FOR XML返回查询结果，可以让用于SQL Server的.NET框架数据提供程序使用SqlCommand.ExecuteXmlReader方法直接创建一个XmlReader。 .NET框架中有一些类，公开用于SQL Server 2000的XML的功能。这些类可在Microsoft.Data.SqlXml命名空间中找到，它们添加了执行XPath查询和XML模板文件以及将XSLT转换应用到数据的能力。 SQLXML托管类包含在用于Microsoft SQL Server 2000的XML (SQLXML 2.0)发行版中，可通过链接XML for Microsoft SQL Server 2000 Web Release 2 (SQLXML 2.0) 下面是一些编写ADO.NET代码时的通用技巧。 就像大多数数据源一样，DataSet使您可标识那些添加新行时自动对其值进行递增的列。在DataSet中使用自动增量的列时，如果自动增量的列来自数据源，可避免添加到DataSet的行和添加到数据源的行之间本地编号冲突。 例如，考虑一个表，它的主键列CustomerID是自动增量的。两个新的客户信息行添加到表中，并接收到自动增量的CustomerID值1和2。然后，只有第二个客户行被传递给DataAdapter的方法Update，新添加的行在数据源接收到一个自动增量的CustomerID值1，与DataSet中的值2不匹配。当DataAdapter用返回值填充表中第二行时，就会出现约束冲突，因为第一个客户行已经使用了CustomerID值1。 要避免这种情况，建议在使用数据源上自动增量的列以及DataSet上自动增量的列时，将DataSet中的列创建为AutoIncrementStep值等于-1并且AutoIncrementSeed值等于0，另外，还要确保数据源生成的自动增量标识值从1开始，并且以正阶值递增。因此，DataSet为自动增量值生成负数，与数据源生成的正自动增量值不冲突。另外一个选择是使用GUID类型的列，而不是自动增量的列。生成GUID值的算法应该永远不会使数据源中生成的GUID值与DataSet中生成的GUID值一样。 如果自动增量的列只是用作唯一值，而且没有任何意义，就考虑使用GUID代替自动增量的列。它们是唯一的，并且避免了使用自动增量的列所必需的额外工作。 按照设计，由于DataSet是与数据源断开的，所以，当多个客户端在数据源上按照开放式并发模型更新数据时，需要确保应用程序避免冲突。 在测试开放式并发冲突时有几项技术。一项技术涉及在表中包含时间戳列。另外一项技术是，验证一行中所有列的原始值是否仍然与通过在SQL语句中使用WHERE子句进行测试时在数据库中找到的值相匹配。 ADO.NET对性能、吞吐量和可伸缩性进行优化。因此，ADO.NET对象不锁定资源，并且必须只用于单线程。一个例外是DataSet，它对多个阅读器是线程安全的。但是，在写的时候需要将DataSet锁定。 ADO.NET的设计目的是成为许多应用程序的最佳解决方案。但是，有些应用程序需要只有使用ADO对象才有的功能，例如，ADO多维(ADOMD)。在这些情况下，应用程序可以用COM Interop访问ADO。注意使用COM Interop访问具有ADO的数据会导致性能降低。在设计应用程序时，首先在实现用COM Interop访问ADO的设计之前，先确定ADO.NET是否满足设计需求。 关于可用数据提供程序的信息，以及每个数据提供程序最适合哪个数据源。 提供程序：SQL Server .NET数据提供程序 详细信息：可在System.Data.SqlClient命名空间中找到。 适用于：使用Microsoft SQL Server 7.0版或更高版本的多层应用程序。使用Microsoft Data Engine (MSDE)或Microsoft SQL Server 7.0版或更高版本的单层应用程序。对于Microsoft SQL Server 6.5版和更早版本，必须将用于SQL Server的OLE DB提供程序与OLE DB .NET数据提供程序一起使用。 提供程序：OLE DB .NET数据提供程序 详细信息：可在System.Data.OleDb命名空间中找到。 适用于：使用Microsoft SQL Server 6.5版或更早版本，或支持任何一种实现了OLE DB接口的OLEDB数据提供者开发的多层应用程序。在.NET Framework SDK中列出了所有的OLE DB接口（注意：不需要OLE DB 2.5接口）。对于Microsoft SQL Server 7.0或更高版本，建议使用SQL Server的.NET框架数据提供程序。使用Microsoft Access数据库的单层应用程序。不建议多层应用程序使用Access数据库。ODBC (MSDASQL)的OLE DB提供程序被屏蔽掉了。需要访问开放式数据库连接(ODBC)数据源，可以下使用ODBC .NET数据提供程序，.NET framework SDK 1.1版包含这一提供程序。 提供程序：ODBC .NET数据提供程序 详细信息：可在Microsoft.Data.Odbc命名空间中找到。提供对通过ODBC驱动程序连接的数据源的访问。 注：ODBC数据提供程序包含在1.1以上版本的.NET framework中。包含的ODBC .NET数据提供程序的命名空间是System.Data.Odbc。 提供程序：用于Oracle的.NET数据提供程序 详细信息：可在System.Data.OracleClient命名空间中找到。提供对Oracle数据源（版本8.1.7及更高版本）的访问。 注：用于Oracle的.NET数据提供程序包含在1.1以上版本的.NET framework中。 提供程序：自定义.NET数据提供程序 详细信息：ADO.NET提供了最小的一组接口，使您能实现自己的.NET框架数据提供程序。有关创建自定义数据提供程序的更多信息，请参阅.NET framework SDK中的。 提供程序：SQLXML托管类 详细信息：用于Microsoft SQL Server 2000的XML发布(SQLXML 3.0)包含SQLXML托管类，它能从.NET框架访问Microsoft SQL Server 2000及其更高版本的XML功能。例如，这些类使您可以执行XML模板、对服务器上的数据执行XML路径语言(XPath)查询、或者用Updategrams或Diffgrams执行数据更新。 SQLXML 3.0以SQLXML 1.0及2.0的功能为基础，为SQL Server 2000引入了Web服务。对于SQLXML 3.0，存储过程和XML模板能通过SOAP公开为Web服务。 可以从网上下载。