.NET小结之数据访问演进

Long long ago,每个数据库的提供商都有自己的API去操作数据库,这样程序和数据库被绑定到了一起,想换数据库基本没门,除非重写程序。

 

 

 

程序员表示强烈抗议,于是一些制定标准的机构(X/OPENISO/IEC)和牛X的公司探讨并提出了CLICall-Level Interface使每个不同的数据库提供的驱动基本相同,这样程序更换数据库方便了很多,但是程序还需要重新编译,后来微软提出了ODBC(Open Database Connectivity)ODBC定义了访问数据库的API一个规范,这些API独立于不同厂商的DBMS,也独立于具体的编程语。ODBC可以动态封装CLI,终于程序和各个数据库提供商不在关联。

.NET小结之数据访问演进

为了满足软件发展的需要,后来微软提出了基于对象的dao(data access obejct,数据存取对象),rdo(remote data object,远程数据对象),dao/odbcdirect(daoodbc直接存取),ado(activex data object,活动数据对象),让人眼花缭乱,而各种技术之间互不通用,也使得每选择一种存取界面都要重新学习,加重了开发人员的负担。

于是微软提出了UDA(universal data access,通用数据访问,也叫全局数据访问)设想,对现有的数据库访问API进行再次封装。UDA 通过一个基于 COM 的编程接口,提供访问任何类型(关系型、非关系型和层次结构型)数据的功能。

OLE DB 是微软对UDA思想的具体实施。

.NET小结之数据访问演进

看似OLEDB已经很完美了,但是悲剧的是当时ASP 和 Visual Basic 不能直接使用OLEDB,而当时无数项目使用在使用VB和ASP。因此微软又推出了更加方便使用的ActiveX 数据对象(ActiveX Data Objects ,ADO) 库,ADO比OLE DB提供更丰富的编程接口。ADO 主要依靠 OLE DB 服务来添加其扩展功能,比如当时采用了访问断开链接模型来提升web应用程序的可扩伸缩性,建立连接、提取数据、脱机处理、需要的时候再次连接提交更改,这样极大的提高了程序的可扩展性和伸缩性。这样不得不让人思考,OLEDB架构的灵活性可以完成脱机工作的任务,而当时很多程序已经依赖了ADO,在断开连接的情况下再使用OLEDB,但是ADO的接口和OLEDB  API有很大的差异性,不得不让人心存忧虑。这些问题将在ADO的后续版本ADO.NET得以解决。

 

ADO.NET 是对传统 ADO 的改进,可用于创建分布式的数据共享应用程序。它是一种高级的应用程序编程接口,面向支持对数据进行断开连接访问的松耦合的、n 层的、基于 Internet 的应用程序。

.NET小结之数据访问演进

                     (ADO.NET结构图,转自MSDN)

 

ADO.NET 提供了 .NET 托管提供程序以便进行连接访问,并且提供了以 XML 格式读取和写入的数据集,以便对已检索的数据和用户交互进行断开连接管理。

.NET小结之数据访问演进

大多数情况下,并非新技术取代“旧”的技术,而是多种技术并存向下兼容的状态。下面这张图是我山寨MSDN的,阐明了数据访问栈,并说明了 ADO.NET 与其他数据访问技术(包括 ADO 和 OLE DB)之间的关系。

.NET小结之数据访问演进

                                                    (数据访问栈)

你可能感兴趣的:(.net)