Long long ago，每个数据库的提供商都有自己的API去操作数据库，这样程序和数据库被绑定到了一起，想换数据库基本没门，除非重写程序。
程序员表示强烈抗议，于是一些制定标准的机构(X/OPEN、ISO/IEC)和牛X的公司探讨并提出了CLI（Call-Level Interface）使每个不同的数据库提供的驱动基本相同，这样程序更换数据库方便了很多，但是程序还需要重新编译，后来微软提出了ODBC(Open Database Connectivity)，ODBC定义了访问数据库的API一个规范，这些API独立于不同厂商的DBMS，也独立于具体的编程语。ODBC可以动态封装CLI，终于程序和各个数据库提供商不在关联。
为了满足软件发展的需要，后来微软提出了基于对象的dao（data access obejct，数据存取对象），rdo（remote data object，远程数据对象），dao／odbcdirect（dao／odbc直接存取），ado（activex data object，活动数据对象），让人眼花缭乱，而各种技术之间互不通用，也使得每选择一种存取界面都要重新学习，加重了开发人员的负担。
于是微软提出了UDA（universal data access,通用数据访问，也叫全局数据访问）设想，对现有的数据库访问API进行再次封装。UDA 通过一个基于 COM 的编程接口，提供访问任何类型（关系型、非关系型和层次结构型）数据的功能。
OLE DB 是微软对UDA思想的具体实施。
看似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 的应用程序。
（ADO.NET结构图，转自MSDN）
ADO.NET 提供了 .NET 托管提供程序以便进行连接访问，并且提供了以 XML 格式读取和写入的数据集，以便对已检索的数据和用户交互进行断开连接管理。
大多数情况下，并非新技术取代“旧”的技术，而是多种技术并存向下兼容的状态。下面这张图是我山寨ＭＳＤＮ的，阐明了数据访问栈，并说明了 ADO.NET 与其他数据访问技术（包括 ADO 和 OLE DB）之间的关系。
（数据访问栈）