ado.net的不足
2009-07-19 15:07 Peter Yao 阅读(375) 评论(0) 编辑 收藏 举报简言之,在过去的这些年里,数据访问的需求发生了变化,这样就需要对先前的数据访问技术做相应的调整。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应运而生。