当前位置: 首页 > 图文教程 > 网络编程 > ASP.NET > ADO.NET:通向未来之桥

ASP.NET
使用函数传递参数来执行相应的数据库操作
如何实现在窗体和窗体之间进行传递数据
ASP.NET中文显示之两种解决方法
ASP.NET、JSP及PHP之间的抉择
ASP.NET 2.0发送电子邮件中存在的问题
谈谈HtmlControl与WebControl的区别与用途
从ASP.NET 1.1升级到ASP.NET 2.0要考虑的Cookie问题
通过系统配置来提高ASP.NET应用程序的稳定性
妙用ASP2.0中的URL映射改变网址
AJAX实现web页面中级联菜单的设计
ASP.NET跨页面传值技巧总结
再议ASP.NET DataGrid控件中的“添加新行”功能
Geometry 对象浅析
重构CollapsibleSplitter
如何利用.NET Framework使用RSS feed
ASP.NET获取IP与MAC地址的方法
在ASP.NET 2.0中使用样式、主题和皮肤
ASP.NET中为GridView添加删除提示框
ASP.NET 2.0,无刷新页面新境界
看看一个.net版对话框控件

ASP.NET 中的 ADO.NET:通向未来之桥


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-11-03   浏览: 57 ::
收藏到网摘: n/a

    在Web跨入编程时代之前,对于大多数IT管理者和顾问来说,数据访问只是一个相对而言的问题;所有要用到的数据都必须自己准备好。人们主要关心的问题是选择性能/价格比最好的数据库服务器,系统涉及的所有模块必须和服务器兼容。客户机/服务器应用是这种两层模型最典型的范例。

    随着Web交互性的日益提高和应用的日益广泛,对于第三层——中间层的需求也越来越突出。中间层是一个逻辑层,数据访问组件通常就在这一层上。数据访问组件是唯一有必要了解数据库细节的代码,同时,准备更换或者升级数据库服务器时,数据访问组件也是第一个需要修改的地方。

    接下来,三层系统模型发展成了Windows DNA——现在称为Microsoft .NET服务器系统。Microsoft利用一个统一的模型进行数据访问。这个模型注重的是内容,而不是数据格式和存储媒介。它的具体表达方式建立在UDA(Universal Data Access,通用数据访问)的基础之上,而UDA正是激励OLE DB体系发展的深层理念。为了提供一种通过VB和ASP COM组件方便地、无缝地访问OLE DB功能的途径,Microsoft设计了ADO。ADO 2.0是用来支持OLE DB的第一个版本。在几年之内,ADO发展到了2.6版本,增加和扩展了XML支持,使得经过扩展的ADO对象模型能够匹配所有OLE DB改进功能(例如,对于OLE DB新增的Row和Stream对象,ADO 2.5提供了类似的ADO配套功能)。

    ADO 2.0的核心功能超越了OLE DB。在多层系统中,随着中间层组件的出现,如何为表现层提供最新数据这一问题也随之出现。表现层怎样访问数据?连接怎样打开?或者,我们是否应该维护一份脱机记录(即,一些断开连接之后仍旧能够在表现层使用的数据库记录)?ADO 2.0以及它的更高版本同时提供了对服务器端游标和脱机记录集的支持(脱机记录集是一种COM对象,它可以跨越网络串行化,客户可以下载它然后脱机使用)。 

    服务器端游标代表着一个紧密结合的、保持连接的环境,在这个环境中我们总是维持着各个层之间的有效通道,只有结束时才拆除连接。与此相反,脱机记录集是一个有状态的对象,我们可以把它作为一个整体处理,且不必维持连接。脱机记录集使用客户端的静态游标,能够提供一个数据源的快照。对于那些只有读取要求、且需要在各个系统层之间移动数据的应用程序来说,脱机记录集是很理想的。今天,大多数Web应用程序要求在各个层之间传输数据。为了获取这些数据,我们经常使用快速的“只能向前”游标,用XML编码数据,然后通过网络发送数据,避免了在Web服务器上维持会话状态信息。在分布式环境中,数据库连接是一种关键性的资源,以脱机方式工作保证了高可伸缩性。

    然而,Web是一把双刃剑。Web让我们连接到任何类型的联机服务,而且能够与它们进行交互。但是,Web也要求一定程度的互操作性,因为操作所涉及的各个服务可能运行在不同的软件和硬件平台上。我们可以通过利用开放的标准,以及那些不注重私有权的技术——甚至是象COM+这类广泛应用的私有技术,跨越不同的平台。

    今天,基于Windows的Web数据访问应用程序利用了ADO丰富的、方便的编程接口。然而,ADO对象天生地定位在Windows平台上。ADO基于COM的本性使得记录集很难在一个分布式、异种平台构成的环境中使用。另外,即使目标平台可能允许我们使用ADO记录集,它也不具备最有效的机制。ADO.NET的DataSet和DataReader更有效;而且,如果没有ADO.NET,有些时候我们还可以借助XML或纯文本获得高效率。

    为了在Web环境下传输数据,Microsoft对ADO记录集进行了优化。但COM类型转换仍旧是一个必不可少的步骤,因为COM的数据类型不可能总是匹配ADO记录集的数据类型(例如,String类型必须转换成BSTR类型)。由此,许多人把XML当成了粘合各个层的“万能胶水”——不管涉及到了哪些平台。通常的做法是:先提取一个记录集,把它保存为XML格式,然后传输结果数据流,让接收者从这个XML数据流重新构造出记录集供以后使用。随着对协同工作能力和可伸缩性要求的提高,ADO不再是最理想的答案,因为它不是建立在XML的基础上——但ADO.NET是。

二、ADO在Web环境中的不足

    .NET框架创立了一种取代COM和COM+的新组件模型。.NET的提出是Microsoft成熟的组件技术的新战略。虽然几个关键性的COM特色不再在.NET中出现,但在某些方面,.NET与COM编程仍旧很相似。因此,COM程序员将能够方便地转向.NET开发。ADO.NET是Microsoft特别为.NET框架设计的数据访问层,它在很大程度上利用了.NET的优势。

    为什么.NET必须用一个新的数据访问层来替代现有的、广泛应用的数据访问接口,比如ADO?现代Web应用系统必须具备客户机/服务器应用和桌面应用的交互能力,Microsoft设计.NET的目标正是为了迎接设计现代Web应用系统的挑战。同时,.NET也利用了各种Web协