Ado.Net的不足

    在ADO.NET作为.NET框架的一部分推出之前，ADO（ActiveX Data Object）是微软平台上的数据访问技术。一个很显而易见的问题是：为什么在大家都已经很熟悉的ADO能实现同样功能的情况下，微软要去启用一个全新的数据访问技术？推而广之，这个问题可以扩展为“DAO、RDO、ODBCDirect、OleDb以及ADO有什么不足之处？”

也就是说，在过去的这些年里，数据访问的需求发生了变化，这样就需要对先前的数据访问技术做相应的调整。ADO主要通过非托管（unmanaged）代码访问数据，而在.NET中就要通过一个标准的访问COM对象的机制，去编写非托管代码以访问ADO对象，这种访问COM对象的机制称为交互（interop）。与完全的托管代码相比，通过交互访问非托管代码时不仅会有性能的损耗，还会有悖于.NET的安全控制。并且，非托管代码会遇到原先在编程模型下的诸如DLL地狱（DLL Hell）之类的问题，针对基于交互的对象的垃圾收集实现得也不够理想。你可能已经了解到，在很大程度上，.NET下的垃圾收集能减轻每个程序清除其空闲内存的负担。这个功能在COM环境下不可用，需要依赖于引用计数器来实现内存管理。如果架构有问题，那么交互的COM组件就可能无法与新的垃圾收集模型一起工作，甚至可能导致内存泄漏。最后要注意的是在数据层的内存泄漏的问题，这通常是应用程序中最为关键的部分，它与性能和可靠性同样重要。

    Ado的另一个大缺陷是，它在设计时没有考虑与XML一起工作，XML是后加的，而且那些使用过ADO的人都知道，虽然Recordset可以转换成XML，但所产生的XML是很难读懂的，而且在不同的对象之间并不能随心所欲地移植。相反，ADO.NET则是基于这些需求从头开始设计的。

按照同样的思路，在开发ADO时，Web服务和整个非连接的计算概念还处在早期。随着非连接计算和对集中式数据库的大量需求的激增，很显然需要一种新的数据访问架构——必须支持更好的并发、池化、XML支持以及非连接的架构。因此，ADO.NET应运而生。

转载于:https://www.cnblogs.com/xfxr/archive/2009/07/26/1531618.html