ADO.NET：不仅仅只是对ADO的升级

　　
　　有时候，新改进的产品和原有产品的差别非常巨大，以至于其相似之处只是名称。这就意味着这个（改进的）产品肯定是新的，但是仍然需要进一步检查才能确定它是否真的得到了改进。对于ADO.NET来说，情况就是这样的；它和ADO同名，但是两者的相同点仅此而已。
　　
　　从头开始
　　
　　
　　
　　经典的ADO和ADO.NET里的一切都是从Connection（连接）对象开始的。Connection对象表示对数据源的唯一物理连接，但是两者就这么一点相同之处。尽管Connection对象的不同更加复杂（也就是说，连接是如何处理的），但是这些不同点的范围是很大的。在经典的ADO里，在连接被创建和建立的时候，应用程序能够按照自己的需要保持这个连接。事实上，应用程序没有被限制只能建立一个连接；它们可以建立多个连接。但是由于连接是有限的资源，所以这种方法还需要考虑其他一些问题。
　　
　　ADO.NET对连接采取了不同的方法。连接只被保持足够长的时间来完成一项操作。一旦这项操作被完成，Recordset就被立即断开。命令的结果被读入Dataset，在这里这些结果能够被处理，即使它们同数据源已经断开。虽然经典的ADO也能够进行离线处理，但是ADO是一个极其好的例子，能够说明有可能同轻易实现之间的差别。
　　
　　在ADO.NET里，节省连接资源的方法同其处理更新的方法是一样的。当Dataset发生变化的时候，由于ADO.NET的离线属性，这些变化不会立即反映到真实的表格上。要让变化“真正地”发生，你就需要使用DataAdapter对象，它被用来进行填充操作以及从Dataset或者对Dataset进行更新。
　　
　　ADO.NET的DataAdapter对象有四个方法来从数据源取回数据或者对数据源更新数据。这些方法是：SelectCommand、InsertCommand、UpdateCommand和DeleteCommand。这些方法最好的地方是：一旦知道了名称，你就它们能够做什么了。
　　
　　
　　
　　说再见
　　
　　在经典的ADO里，Recordset曾是访问数据的主要方法。它就像执行查询一样简单，使用从一个或者多个表格请求得来的列就能够创建一个Recordset。在多个行（记录）被返回的情况下，就要通过使用move、moveNext、movePrevious、moveLast或者moveFirst这些方法来实现导航。当然不是所有这些方法都能使用，因为使用了只能向前的指针（forward-only cursor），所以在这种情况下只能允许使用moveNext、moveLast和move（如果向前移动）。
　　
　　在ADO.NET里，Recordset已经被取消了，而指针也只留有其概念。它们已经被提供相同功能的数据类所取代。例如，我用过的大多数经典的ADO指针都是只能向前、只读的，因为我是那些相信最好尽快就能完成输入输出的开发人员之一。随着ADO.NET的出现，由DataReader对象提供了只能向前的、只读的指针所提供的功能。
　　
　　
　　新的特性和改进的内容
　　
　　
　　
　　ADO.NET最可吹嘘的特性是其数据访问的离线方法，这是可以得到证明的。但是这也是受到误解最多的特性之一。在我当前被分配设计ASP网上商店的时候，在有些会议上，只要.NET一被提到，马上就会引起激烈的争论。
　　
　　为什么会引起激烈的争论？嗯，Dataset驻留在内存里的观念曾经被理解为“整个数据库都被保存在客户机器的内存里”。消除这种看法需要花上一些时间，但是最终，持这种看法的人都被说服，因为他们了解到ADO.NET和ASP.NET都不会这样工作，当然，除非要求它们这样做。
　　
　　ADO.NET对象驻留内存的性质是其强项。它提供了操控数据的强大能力，在经典ADO里如此操控数据曾经是很困难的，如果不是不可能的话。ADO.NET和XML现在相互进行了集成。对于ADO来说，使用ADO的Recordset来生成XML文档是相对容易的，但是反过来就没有那么容易了。要从一个XML文档生成一个ADO的Recordset需要大量的代码。但是由于ADO.NET和XML进行了相互集成，因此使用XmlDataDocument就能够进行相互转换。
　　
　　这种和XML的集成不仅仅能够用于和XML的相互转换；它让把Dataset作为XML对待成为了可能。XSLT、Xpath和Xquery都可以和Dataset一起使用，这就有了很多选择，在经典的ADO里实现这些选择需要一些难以理解的代码。
　　
　　
　　
　　吹嘘之外的东西
　　
　　对ADO.NET的吹嘘掩盖了这样一个事实：它并不真的是经典ADO的升级――它完全是使用了原有名字的新产品。许多当前正在使用经典ADO的人会被ADO.NET吓住，因为它在如何访问信息以及如何处理它所访问的信息上有太多的选择。但是我认为，灵活性更强的ADO.NET会最终取代经典的ADO，因此现在对其的抵制都是徒劳的。
　　

查看本文来源