ADO.NET的开发场景及传统ADO的处理

批量更新

　　ADO Recordset对象经常会用到的一种情形是进行批量更新。例如，在一个N层应用程序中，ADO Recordset可检索一个行集，将其从数据源中断开连接，并将Recordset发送到客户端层。在客户端应用程序中，对几行的更改将在断开连接的ADO Recordset中进行。然后Recordset可被发回给中间层，通过ADO Connection对象与数据库重新连接，其更改可通过UpdateBatch方法应用于数据库。UpdateBatch方法将接受Recordset中的所有被更改的行，并将更改应用于Recordset源查询中指示的源表。ADO.NET也有内置的处理批量更新的功能。DataSet是一个自成一体的、总是断开连接的行集集合，它可以存储行集中行与列的原始值和当前值。DataSet可以被发送给客户端应用程序，由后者进行更改操作。DataSet然后被发送到中间层，其更改将通过DataAdapter对象应用于数据库。图2说明了ADO.NET DataAdapter如何使用其不同的Command对象执行SELECT、INSERT、UPDATE和DELETE SQL命令：

//-- Setting the ADO.NET DataAdapter's command objects oDa.InsertCommand = oInsCmd; oDa.UpdateCommand = oUpdCmd; oDa.DeleteCommand = oDelCmd; oDa.Update(oDs.Tables["Orders"]);

　　ADO.NET技术在对数据库应用更新的方式上比传统的ADO批量更新技术更灵活。传统ADO是通过查看ADO Recordset的Source属性来确定保存更改的位置。例如，假定Recordset的源是：

SELECT OrderID, CustomerID, OrderDate, ShipCity, ShipCountry FROM Orders

　　这种情况下，在对Recordset已经进行批量更改而且调用了Recordset的UpdateBatch方法之后，Recordset必须指向发送更改的位置。它查看源的SQL语句，并确定Orders表的主键(OrderID)在语句中而且只用到了一个表。因此，它可以使用SQL语句创建UPDATE、INSERT和DELETE语句对Orders表进行处理。为了能够派生操作查询，Recordset必须知道唯一行标识符。同样，存储过程不能用于这种技术更新数据库，因为语句是隐式创建的。以下ADO 2.x代码说明了包含Orders的Recordset如何在客户端应用程序中进行更新：

'-- Using traditional ADO, '-- Updating two rows in the client tier oRs.Find "CustomerID = 'VINET'" oRs.Fields("ShipCity") = "Somewhere" oRs.Update oRs.Find "CustomerID = 'CHOPS'" oRs.Fields("ShipCity") = "Elsewhere" oRs.Update

　　之后，一旦Recordset传回给中间层，将调用以下代码从而将已完成的更改应用于数据库：

'-- Using traditional ADO, '-- Sending both updated rows to the database, in the business tier oRs.UpdateBatch

　　ADO.NET CommandBuilder的工作方式与此类似，因为它可以自动地为DataAdapter生成UpdateCommand、InsertCommand和DeleteCommand对象。自动生成命令的过程也会带来系统开销。显式地指定要使用的INSERT、UPDATE和DELETE语句效率更高。与显式指定命令相比，使用ADO.NET CommandBuilder意味着性能更低下，在对数据源应用更改方式上的控制也更差。准确的SELECT、INSERT、UPDATE和DELETE语句通常在设计时是已知的，可以用来生成ADO.NET DataAdapter的四个不同Command属性，它们甚至可以用存储过程的名称表示。ADO.NET的这一功能是传统的ADO所缺乏的一个关键部分，这可以大大提高传统ADO的批量更新技术的灵活性。当然，这需要在设计时进行更多的编码工作，但为了获得它所提供的更大灵活性（可使您非常具体地指定SQL语句或更常见地用于为每个操作指定存储过程），付出这些努力也是值得的。

　　断开连接的行集

　　通过适当设置一些属性，ADO Recordset对象可以从其数据源中断开连接。通过断开连接，它能够在内存中存储整个行集，并在使用传统ADO的应用程序之间传递。以下代码示例将断开Recordset的连接：

'-- Disconnecting an ADO Recordset oRs.CursorLocation = adUseClient oRs.CursorType = adOpenStatic oRs.LockType = adLockBatchOptimistic oRs.Open Set oRs.ActiveConnection = Nothing

　　断开Recordset的连接涉及的关键属性是CursorType和CursorLocation。CursorLocation必须设置为adUseClient，表示行集应该存储在Recordset的内存中。CursorType应该设置为adOpenStatic，这将允许行集的游标能够在任何方向上移动，但是不允许行集自动对基础数据库的更改处于敏感状态。通过结合使用这两个设置，Recordset可以断开连接，但是，全部步骤还没有完。一旦打开Recordset，因为它真的断开连接了，那么它的ActiveConnection属性应该被设置为关键字Nothing，就像上一个代码示例中看到的那样。构建ADO Recordset是为了在断开连接和已连接这两种模式下工作。但是在ADO.NET中，当DataSet完全断开连接时，DataReader要维持连接。DataSet是断开连接的ADO Recordset的继承者，因为它实现了一个客户端游标，可以向任何方向滚动，而且ADO.NET DataSet还支持许多其他功能。传统的ADO Recordset对象提供的断开连接功能非常有限，而ADO.NET DataSet对象是专门为断开连接而设计的。与Recordset不同，DataSet可以在DataTable对象内存储和表示多个行集，甚至还可以使用DataRelation对象将它们互相联系起来。下面是使用SqlDataAdapter的Fill方法创建和填充DataSet的一种常见方式：

//-- Creating and filling an ADO.NET DataSet DataSet oDs = new DataSet("MyDataSet"); oDa.Fill(oDs);

　　DataSet可以施加关系、主键约束和外键约束，甚至实现列表达式。ADO Recordset还能够使用它的数据构形功能返回层次化的结果。虽然有这些层次化功能，但是它们需要使用我个人认为非常笨拙的数据构形语法。就此方面而言，ADO.NET DataSet更加高效也更加直观，因为它就是为使用其DataRelation和DataTable对象处理关系数据结构而构建的。

　　在之前，我讨论了几个传统的ADO 2.x开发中常用的技术，以及如何将它们转换到ADO.NET。ADO.NET是ADO 2.x发展的下一阶段，许多传统ADO中的功能都将在ADO.NET中进行全面改造。例如，ADO 2.x中添加了Open和Save方法的功能以支持XML，而XML支持从一开始就已经被纳入到ADO.NET的设计蓝图中了。ADO的一些功能发生了很大变化，变化之一就是Recordset的许多游标类型被分为多个不同的各有侧重的对象，例如DataReader、DataSet和DataAdapter。其他功能（例如Connection和Command类）的改变则不是那么明显。但是，说到底，从ADO到ADO.NET的迁移还是相对比较易懂的，这是因为ADO.NET的设计构筑于传统ADO的使用体验之上。

查看本文来源