当转为使用ADO.NET时，您将需要了解如何应对以前知道用ADO处理而现在必须用ADO.NET解决的场景。就像使用Visual Basic、C++和ASP开发的N层解决方案经常要依赖ADO来满足数据访问需要一样，Windows?窗体、Web窗体和Web服务也要依赖ADO.NET。我曾经从使用传统ADO开发的角度讨论了如何使用ADO.NET来处理一些数据访问的场景。其中的一些主题包括将行集保留为XML、处理只进流水游标和执行Command对象的多种方式。在文中，我将继续讨论使用ADO.NET的开发场景，以及使用传统的ADO技术是如何处理的。我将从经常使用的传统ADO的只进、静态、键集和动态游标的情况开始讨论。我还要讨论如何处理并发性问题，以及断开连接的行集如何从ADO演变到ADO.NET。然后，我会说明如何将使用传统的ADO处理批量更新的代码转换为使用ADO.NET（用DataAdapter及其四个命令对象）的代码。
分散Recordset的功能
在ADO.NET中，ADO Recordset的大多数功能都分到了三个主要对象中：DataReader、DataSet和DataAdapter（参见图1）。
图1 ADO Recordset
ADO.NET DataReader对象被设计成服务器端的只进、只读游标。ADO.NET DataSet对象是行集断开连接的存储工具。它存储记录，但不持有与数据源的连接，事实上，它并不关心其行集从哪个数据源派生。DataSet在内存中存储时是一个二进制对象，但是它可以轻松地从XML序列化和序列化为XML。这与ADO Recordset对象从其相关联的Connection对象断开连接（通过Recordset的ActiveConnection属性）时将CursorType设置为adOpenStatic、将CursorLocation设置为adUseClient是类似的。ADO.NET DataAdapter对象是连接与DataSet对象之间的桥梁，它可以通过一个连接从数据源加载一个DataSet，并用DataSet中存储的已更改的内容更新数据源。ADO Recordset的行为取决于其属性的设置（包括CursorType和CursorLocation属性）。在ADO.NET中构建了不同的对象来处理这些特定的情况，而无需用一个对象来应对所有情况。
流水游标
传统的ADO公开了四个不同类型的游标，可以改变ADO Recordset对象的运作方式。ADO Recordset对象的行为方式因其CursorType属性的设置情况互不相同，可能有非常大的差异。例如，通过将CursorType设置为adOpenForwardOnly，Recordset可保持与其数据源的连接，而且必须按只进方向进行遍历。然而，当您将CursorType属性设置为adOpenDynamic时，Recordset可向前或者向后遍历，甚至可以使游标跳到某个特定行。通过其CursorType和CursorLocation属性，ADO Recordset对象采用了一种将许多解决方案包装到单个对象中的方式。而ADO.NET采用的方法则不相同，它设计由不同的对象和方法来处理各种特定情况。在传统的ADO中，只进、只读游标是通过将CursorType设置为adOpenForwardOnly、将CursorLocation设置为adUseServer（这也是默认设置）实现的，这将使Recordset对象采用只进的服务器端游标形式。MoveNext方法将Recordset重定位到下一行，而MovePrevious方法则根本不允许使用，但是可以调用Recordset的MoveFirst方法。这有些容易引起误解，因为该方法并不将Recordset重定位到当前行集的开始；相反，它调用原来的SQL语句，从头开始重新填充Recordset，因此会再次移动到第一个记录。每次执行传统ADO Recordset的MoveFirst方法时（CursorType设置为adOpenForwardOnly），通过打开SQL事件探查器工具，观察SQL的执行情况，可以很容易地看到这一点。在需要逐个遍历成千上万（乃至更多）行中的每行或者在需要小一些的行集但是只需遍历一次（可能为了加载到一个选取列表）时，这种游标是非常常用的：
'-- Forward-only Firehose Cursor in ASP and ADO
Set oRs.ActiveConnection = oCn
oRs.LockType = adLockReadOnly
oRs.CursorType = adOpenForwardOnly
oRs.CursorLocation = adUseServer
oRs.Open sSQL
最接近这种传统的ADO流水游标的等效物是ADO.NET DataReader对象。和传统的只进ADO Recordset一样，DataReader在打开的同时保持着与其数据源的连接，而且只能以前进的方向进行遍历。但是，它们还是有区别的。区别之一是，专门为某个data provider（如SQL Server?（SqlDataReader类）或者ODBC数据源（OdbcDataReader类））编写单独的DataReader类型。ADO.NET DataReader对象非常高效，这是因为它是专门为实现只进、只读游标这一目的而构建的。传统ADO的只进游标是通过相同的Recordset对象（作为一个断开连接的Recordset甚至是一个数据源敏感的Recordset）实现的。而DataReader只是为了作为轻型流水游标而设计的。
//-- ASP.NET and ADO.NET in C#
SqlDataReader oDr = oCmd.ExecuteReader();
数据敏感游标
传统ADO的只进游标现在由DataReader对象处理。但是，对基础数据库中的更改非常敏感的键集和动态服务器端游标（CursorType = adOpenKeySet和CursorType = adOpenDynamic）又怎么样呢？当前版本的ADO.NET并没有公开多方向、可滚动、可更新的服务器端游标。但是，ADO.NET确实提供了许多方式避免使用这些类型的服务器端游标，因为有其他推荐的技术可以考虑。除了使用DataSet结合DataAdapter来检索和更新数据以外，还有一些好的替代方案在客户端使用可滚动的服务器端游标。例如，可以使用存储过程，在运行服务器端SQL处理时这是非常高效的。还可以通过服务器端只进游标用DataReader检索数据，然后用Command对象分别进行更新。但是，经常有比使用可更新的服务器端游标更高效的修改数据的方式。
在一个N层环境中，服务器端可滚动游标的问题之一在于，它们需要在服务器上保持状态。因此，如果应用程序在中间层使用服务器端可滚动游标，客户端层就需要维持与可滚动游标所在的业务层的连接。这样，在同样使用可滚动游标的客户端应用程序屏幕存在期间，业务对象都需要保留。各种文档中已经很好地记录了这些可伸缩性问题，但是，在一些情况下服务器端游标还是很有价值的，如需要只进流水游标的情况。例如，在应用程序需要注重数据并发性问题的时候就要用到服务器端游标。使用传统的ADO，Recordset可以用一个动态游标打开，这种游标使Recordset能够获悉所有其他用户进行的插入、更改和删除操作。这种服务器端游标对于其他用户所做的更改非常敏感，可以在应用程序出现并发性问题的时候用于采取主动措施。例如，传统ADO中的动态游标经常用于这样的场合：应用程序准备在数据库中保存更改，但是又需要确保首先知道是否有其他人更改了同一条记录。当用户更改动态Recordset中一个记录值的时候，该值将自动在服务器端动态Recordset中更新：
'-- Dynamic Cursor in ASP and ADO
Set oRs.ActiveConnection = oCn
oRs.LockType = adLockOptimistic
oRs.CursorType = adOpenDynamic
oRs.CursorLocation = adUseServer
oRs.Open sSQL
服务器端游标与并发性
并发性问题在许多企业级应用程序中是合理而且常见的问题，但是使用服务器端游标以解决这一问题的代价却可能非常之高。那么在ADO.NET中有什么替代方式处理并发性问题呢？常见的技术是允许应用程序对数据库提交更改，然后在遇到并发性问题时引发特殊类型的异常。有一个特殊类型的异常名为DBConcurrencyException，它是从Exception基类派生而来的。因为DataSet将每列的原始值和拟更改值存储到一行中，它知道如何将值与数据库进行比较以自动寻找并发性问题。例如，假定用户将firstname字段的值由Lloyd更改为Lamar，并将更改提交给数据库，存储在DataSet中的更改将通过DataAdapter的Update方法传递给数据库。在数据真正保存之前，如果数据库中的名字不再是Lloyd，现在变成了Lorenzo，将会引发一个DBConcurrencyException异常。此异常可以以最适合应用程序需要的任何方式进行捕获和处理，例如，可以采取“最后者优先”的规则，使用户可以选择取消更改、改写或者强制更新或其他技术。
public DataSet SaveData(DataSet oDs)
{
string sMethodName = "[public void SaveData(DataSet oDs)]";
//==========================================================
//-- Establish local variables
//==========================================================
string sProcName;
string sConnString = "Server=(local);Database=Northwind;Integrated
Security=SSPI";
SqlDataAdapter oDa = new SqlDataAdapter();
SqlTransaction oTrn = null;
SqlConnection oCn = null;
SqlCommand oInsCmd = null;
SqlCommand oUpdCmd = null;
SqlCommand oDelCmd = null;
try
{
//==========================================================
//-- Set up the Connection
//==========================================================
oCn = new SqlConnection(sConnString);
//==========================================================
//-- Open the Connection and create the Transaction
//==========================================================
oCn.Open();
oTrn = oCn.BeginTransaction();
//==========================================================
//-- Set up the INSERT Command
//==========================================================
sProcName = "prInsert_Order";
oIn
