当转为使用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
服务器端游标与并发性
并发性问题在许多企业级应用程序中是合理而且??A href=http://cs.mimi163.net/cs/question.php>问题,但是使用服务器端游标以解决这一问题的代价却可能非常之高.那么在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";
oInsCmd = new SqlCommand( sProcName, oCn, oTrn );
oInsCmd.CommandType = CommandType.StoredProcedure;
oInsCmd.Parameters.Add( new SqlParameter( "@sCustomerID", SqlDbType.NChar, 5, "CustomerID" ) );
oInsCmd.Parameters.Add( new SqlParameter( "@dtOrderDate",
SqlDbType.DateTime, 8,"OrderDate" ) );
oInsCmd.Parameters.Add( new SqlParameter( "@sShipCity",
SqlDbType.NVarChar, 30, "ShipCity" ) );
oInsCmd.Parameters.Add( new SqlParameter( "@sShipCountry", SqlDbType.NVarChar, 30, "ShipCountry" ) );
oDa.InsertCommand = oInsCmd;
//================================================
//-- Set up the UPDATE Command
//=================================================
sProcName = "prUpdate_Order";
oUpdCmd = new SqlCommand( sProcName, oCn, oTrn );
oUpdCmd.CommandType = CommandType.StoredProcedure;
oUpdCmd.Parameters.Add( new SqlParameter( "@nOrderID", SqlDbType.Int, 4, "OrderID" ) );
oUpdCmd.Parameters.Add( new SqlParameter( "@dtOrderDate", SqlDbType.DateTime, 8,"OrderDate" ) );
oUpdCmd.Parameters.Add( new SqlParameter( "@sShipCity", SqlDbType.NVarChar, 30, "ShipCity" ) );
oUpdCmd.Parameters.Add( new SqlParameter( "@sShipCountry", SqlDbType.NVarChar, 30, "ShipCountry" ) );
oDa.UpdateCommand = oUpdCmd;
//====================================================
//-- Set up the DELETE Command
//==================================================
sProcName = "prDelete_Order";
oDelCmd = new SqlCommand( sProcName, oCn, oTrn );
oDelCmd.CommandType = CommandType.StoredProcedure;
oDelCmd.Parameters.Add( new SqlParameter( "@nOrderID", SqlDbType.Int, 4, "OrderID" ) );
oDa.DeleteCommand = oDelCmd;
//=================================================
//-- Save all changes to the database
//================================================
oDa.Update( oDs.Tables["Orders"] );
oTrn.Commit( );
oCn.Close( );
}
catch ( DBConcurrencyException exDBConcurrency )
{
//=======================================================
//-- Roll back the transaction
//=======================================================
oTrn.Rollback( );
//--------------------------------------------------------
//-- May want to rethrow the Exception at this point.
//-- This depends on how you want to handle the concurrency
//-- issue.
//--------------------------------------------------------
//-- throw( exDBConcurrency );
}
catch ( Exception ex )
{
//================================================
//-- Roll back the transaction
//================================================
oTrn.Rollback( );
//--------------------------------------------------------
//-- Rethrow the Exception
//--------------------------------------------------------
throw;
}
finally
{
oInsCmd.Dispose( );
oUpdCmd.Dispose( );
oDelCmd.Dispose( );
oDa.Dispose( );
oTrn.Dispose( );
oCn.Dispose( );
}
oCn.Close( );
return oDs;
}
图2 捕获ADO.NET中的并发性问题
在图2 的代码中,可以注意到一个示例方法,它接收一个DataSet参数,并将DataSet中的更改通过DataAdapter的Update方法提交给数据库.如果检测到并发性问题,将由一个特定的catch代码块引发和捕获DBConcurrencyException异常.此时,事务可以回滚,然后还可重新引发异常,直到最终异常被客户端应用程序捕获,从而得以通知用户并询问用户希望如何处理.这里同样要仔细地考虑catch代码块的顺序.例如,如果首先出现一般性的catch代码块,那么它已经捕获了并发性问题.异常处理的关键在于,要确保针对更特定异常的catch代码块在其他catch代码块之前出现,从而可由特定catch代码块首先捕获特定异常.
批量更新
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的批量更新技术的灵活性.当然,这需要在设计时进行更多的编码工作,但为了获得它所提供的更大灵活性(可使您非?咛宓刂付⊿QL语句或更?赜糜谖扛霾僮髦付ù娲⒐?,付出这些努力也是值得的.
断开连接的行集
通过适当设置一些属性,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的使用体验之上.
