.NET下使用Oracle数据库、数据库访问技术（下）

在上一篇文章中介绍了.NET下使用Oracle数据提供程序访问Oracle的方法以及较老的数据库访问方式，ODBC,DAO,RDO等。总的说ODBC的出现使得程序员不必在关注与特定的数据库接口进行编程。而是利用数据库驱动来隐藏了不同数据库的差异，提供了统一的数据库编程接口。但是ODBC是C语言风格的接口，对于VB,ASP等程序无法直接使用，于是出现了DAO.RDO等面向对象的接口供程序员使用。

 

一 OLE DB
ODBC，DAO的表现在关系型数据库上已经很好了，但是随着数据的发展，非关系行的数据Excel，XML，邮件等的出现，使得ODBC无法对这些数据进行访问。而随着COM的发展，组件模型的思想也进入了数据库中，于是出现了OLE DB。全名是Object Linking and Embedding DataBase。对象连接与嵌入，简称OLE技术。OLE 不仅是桌面应用程序集成，而且还定义和实现了一种允许应用程序作为软件“对象 ”(数据集合和操作数据的函数)彼此进行“连接”的机制，这种连接机制和协议称为部件对象模型。

      

OLE DB 建立于 ODBC 之上，并将此技术扩展为提供更高级数据访问接口的组件结构。此结构对企业中及 Internet 上的 SQL、非 SQL 和非结构化数据源提供一致的访问。OLE DB 由三个组件构成：数据使用者（例如，一个应用程序）；包含并公开数据的数据提供程序以及处理并传输数据的服务组件（例如，查询处理器、游标引擎）。OLE DB 是一个针对 SQL 数据源和非 SQL 数据源（例如，邮件和目录）进行操作的基于COM的 API。

OLEDB的特点是他的多层组件结构，而最重要的就是她的数据提供程序，正式他隐藏了数据源的不同特征，使得应用程序可以访问关系和非关系型数据库。而各层之间通过Com通信。

 

二 ADO
OLE DB 为 C 和 C++ 程序员及使用其他包含 C 样式函数调用语言的程序员提供绑定。有一些语言（例如 VB 和 VBScript）不提供指针数据类型（地址变量）。因此，这些语言不能使用 C 样式绑定，而且不能直接调用 OLE DB。在此基础上，Microsoft 推出了另一个数据访问对象模型：ADO。ADO 采用基于 DAO 和 RDO 的对象，并提供比 DAO 和 RDO 更简单的对象模型（尽管会产生一些冗余的功能，如现在进行一项操作时可以用不止一种方法）。ADO 中的对象层次结构比 DAO 中的更平缓。ADO 包含一些简化对数据存储区数据的访问任务的内置对象。

 

从上图中可以很清楚的看到，C++直接使用OLEDB进行数据库操作与，而其他的语言是通过ADO数据库访问模型来调用OLEDB进行数据库访问。另外一个要注意的就是ODBC，可以看到一些数据库访问还是通过 ODBC进行，这是因为不是所有的数据库都支持OLEDB。其实C++也可以使用ADO进行访问，但是相比OLEDB他的层次更多。

ADO全称是Activex Data Object，Microsoft 希望拥有断开的数据访问机制，它扩展了 ADO 并推出远程数据服务 (RDS)。RDS 是按照 ADO 建模的，无需实时连接就可以使记录集传输到客户端（例如，Web 浏览器）。然而，如同 ADO 一样，RDS 使用 COM 封送处理将记录集从服务器传输到客户端。

而我也是从ADO开始接触数据库操作的，自己的第一个程序就是使用ADO操作Access，当然如果你还在使用VB等工具，ADO仍旧是你的选择，ADO参考手册：http://www.yesky.com/imagesnew /software/ado/index.html 、、

 

三 ADO.NET
从ADO到ADO.NET，不是简单的升级，而是完全的重构。从ODBC到ADO，从提供统一的数据库编程接口，到提供统一的数据库访问模型，实现了从低层到高层的抽象。但 ADO.NET 满足了 ADO 无法满足的三个重要需求：提供了断开的数据访问模型，这对 Web 环境至关重要；提供了与 XML 的紧密集成；还提供了与 .NET 框架的无缝集成。

   

图 7 显示了 ADO.NET 的结构。但缺少了能够在 ADO 中执行诸多功能的记录集对象。使用过ADO的应该知道 Recoder确实比较好用。而ADO.NET提供了3个代替的对象DataAdapter和DataReader 来获取数据。而 Connection和Command对象则提供了连接和操作数据库的对象。这4个主要对象就构成了.NET Data Provider。 而.NET类库自带的DataSet为离线数据提供了载体。

图 8 显示了应用程序通过 ADO.NET 连接数据库可采用的各种途径。对于SQL SERVER7及以上数据库，SQL Server .NET 数据提供程序通过表格数据流 (TDS) 协议直接和 SQL Server 通讯，而对于非SQL SERVER 数据库则使用OLE DB .NET 数据提供程序,在底层调用OLE DB提供程序来进行通信。这里或许大家有疑问，为什么不在.NET中直接使用OLE DB提供程序,而要增加一层OLE DB .NET 数据提供程序呢？正如前面说的，数据提供程序使得低层接口的统一，而这里是为了.NET中高层的接口也统一。也就是都是用图7中的那些对象进行操作。在使用OLEDB操作数据库时，实际是通过.NET和COM之间进行了相互操作。

 

从上图可以看出ADO.NET的模型，和OLEDB的很相似，有数据提供者和使用者，只是少了OLEDB中间的服务层，当然只是结构上类似而已。而与ODBC也比较相似，数据提供程序类似于数据库驱动。而ADO.NET相对于OLEDB的优势在于托管提供程序并不使用 COM Interop 桥梁来获取和设置数据。而且在数据使用层的 4个对象，也为在开发者提供了统一的变成模型（主要是早ADO.NET）。而对于不支持OLEDB的数据库，.NET仍旧提供了ODBC的数据提供者，来操作ODBC，但不应该使用OLEDB来访问ODBC数据源，因为他可能需要穿越OLEDB和ODBC两层。

现在我们在回头看看.NET中的数据提供程序,在System.Data命名空间下的， SqlClient,Oledb,ODBC,OracleClient。其中后两个是在.NET1.1中集成，而OracleClient在.NET4.0中被标记为了不建议使用。有了上面的了解，在看看OPD.NET，是不是有种豁然开朗的感觉。是否感觉和ODBC 的驱动程序很象。数据提供者可以很容易的被替换，我们要做的就是引入OracelDataAccess.dll来替代 OracleClient这个数据提供者。而在程序中，因为数据使用层的4个对象，统一的数据库的访问，所以我们甚至不需要修改代码就可以让程序很要的运行。（见前一篇的代码）

这里需要注意的是，ADO.NET2.0较之前的1.1，有的很大的变化。因为在1.1中，开发者在使用层，必须正对不同的数据库编写不同的代码，虽然只是吧SqlConnection修改为OledbConnction，但是如果更换数据源，代码需要进行修改，而且在对应多数据库上比较麻烦，而在ADO.NET2.0中，引入了工厂类，每种数据提供者都集成与基类DbProviderFactory工厂类。所以对于那些面向接口编程的代码，不需要修改就能很好的运行，而对于多种数据源的程序也提供了良好的解决方案。

 

四 LINQ 和 ADO Entity FrameWork

伴随着.NET平台，DataSet、DataTable、IList、XML，DBMS，等等众多的数据源，从中获得数据，也不在是那么容易；更为重要的是，作为一个C#程序员，你还必须熟悉SQL（如果SQL都不会，那就....）, 但是我们也要注意到，不同的数据库，SQL不完全相同，虽然有标准SQL；而另外一个方面，在你写SQL时，如果写错一个符号，系统无法检测，只有在运行时才能发现，而且不会检查查询参数的类型，也不支持 IntelliSense ；正式基于这种情况，微软推出了LINQ。

语言集成查询 (LINQ) 使开发人员能够在应用程序代码中形成基于集合的查询，而不必使用单独的查询语言。您可以编写针对各种可枚举数据源（即实现IEnumerable接口的数据源）的 LINQ 查询，可枚举数据源包括驻留在内存中的数据结构、XML 文档、SQL 数据库和DataSet对象等。虽然这些可枚举数据源以多种方式实现，但它们都公开相同的语法和语言构造。由于可以使用编程语言本身形成查询，因此您不必使用编译器无法理解或验证的以字符串形式嵌入的其他查询语言。通过提供编译时类型和语法检查以及 IntelliSense ，将查询集成到编程语言也使 Visual Studio 程序员的工作更有效。这些功能降低了对查询调试和错误修复的需求。LINQ就是希望 "能够达成以单一的一种语法来查询多种不同的对象" 的目的。

 

其中，LINQ to SQL 是适合不需要映射到概念模型的开发人员使用的有用工具。通过使用 LINQ to SQL，您可以直接在现有数据库架构上直接使用 LINQ 编程模型。LINQ to SQL 使开发人员能够生成表示数据的 .NET Framework 类。这些生成的类直接映射到数据库表、视图、存储过程和用户定义的函数，而不映射到概念数据模型。

LINQ 和 ADO.NET：http://msdn.microsoft.com/zh-cn/library/bb399365.aspx

 

微软虽然有了ADO.NET这 个数据访问的利器，但却没有像NHibernate这样的对象对应工具，因此微软在.NET Framework 2.0发展时期，就提出了一个ObjectSpace的概念，ObjectSpace可以让应用程序可以用完全对象化的方法连接与访问数据库，其技术概念与NHibernate相当类似。

 

Entity Framework 利用了抽象化数据结构的方式，将每个数据库对象都转换成应用程序对象 (entity)，而数据字段都转换为属性 (property)，关系则转换为结合属性 (association)，让数据库的 E/R 模型完全的转成对象模型，如此让程序设计师能用最熟悉的编程语言来调用访问。而在抽象化的结构之下，则是高度集成与对应结构的概念层、对应层和储存层，以及支持 Entity Framework 的数据提供者 (provider)，让数据访问的工作得以顺利与完整的进行。
(1) 概念层：负责向上的对象与属性显露与访问。
(2) 对应层：将上方的概念层和底下的储存层的数据结构对应在一起。
(3) 储存层：依不同数据库与数据结构，而显露出实体的数据结构体，和 Provider 一起，负责实际对数据库的访问和 SQL 的产生。

从上面的图可以看出Entity Framework是构建于ADO.NET数据提供程序之上，在低层仍旧是ADO.NET中那一套对象，他为我们对于不同数据库提供了统一的访问方式，不同的是，我们不在需要自己手动的去书写代码。因为在上层，我们使用LINQ，也能以统一的方式来操作各做数据源。但是对于LINQ用的很少，而 Entity Framework还未使用过，所以就没办法过多介绍了。这也是下一步学习的目标了。

 

五 总结

写完了这两篇文章，看到了数据库访问技术，从最原始的面向特定数据库编程；到使用ODBC,OLE DB提供统一数据库访问接口；使用DAO,ADO,ADO.NET的提供高层更抽象的数据库访问对象；以及LINQ、Entity Framework提供更简单，更统一的数据访问模型。给我最大的感受就是软件的发展，或者可以说是软件的进化。其实所做的一切，就是为了统一，为了方便奥运会的口号，更高、更快、更强。我们软件则是更统一、更抽象、更简单。当然随之而来的问题就是封装的更深，我们这些程序员对底层的东西了解的越来越少。所以希望总结的这些东西能对大家有所帮助。真不知道以后的数据访问技术会是什么一个样子。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/cc_net/archive/2009/10/29/4745480.aspx