实战 .Net 数据访问层 - 1

访问|数据

实战 .Net 数据访问层

l 特别说明

本篇实战共分23段,非作者有意如此,乃受CSDN发表文章之64K所限。

虽然有几段根本没有达到64K,但估计是HTML Source超过了这个范

围,所以也不得不单独分段(大都是源代码),请大家谅解。

如果有朋友需要完整文档,请发邮件给我:

mailto:xuefeng.zhang@bearingpoint.com

l 引言

这次的讨论是上一部分“剖析 .Net 下的数据访问层技术”的一个续,但也可独立成章,为突出主题,作者就特意换了一个标题。

关于上次的内容,大家可以参考如下链接:

http://www.csdn.net/Develop/read_article.asp?id=26689(一共六篇,id从26689到26694。也可以通过dev.csdn.net -> Windows/.NET进行访问)

在以下论述中,为统一起见,作者暂时将数据访问层简称为DAL(Data Access Layer)。而在“我的方案”中,作者会介绍另一个“DAL”(Data Access Logic),为避免歧义,所有Data Access Logic将保留全名,不再采用简称。

需要特别说明的是,以下列出的代码全部基于.NET Framework 1.2实现,您也可以在.NET Framework 1.1上进行模拟,但某些ADO.NET 2.0中的更新内容可能无法使用,如:ObjectSpaces,DbDataReader等。

您可以通过两种方法使用.NET Framework 1.2:

(1) 安装Whidbey(Beta)或者Visual Studio .NET 2005(Preview),这是最简单的方法;

(2) 安装.NET Framework 1.2 Runtime(Redistributables),使用Visual Studio .NET 2003(不支持Vistual Studio .NET 2002)进行开发。这种方式需要注意两点:

i. 对于Windows Application,在App.config中进行如下设置:

<configuration>

<startup>

<supportedRuntime version="v1.2.30703"/>

</startup>

</configuration>

对于Web Application,不需要进行什么设置,在安装完.NET Framework 1.2 Runtime后已经自动添加了对IIS的支持;

ii. 虽然可以通过Visual Studio .NET 2003编译支持.NET Framework 1.2的项目,但是调试功能将不起任何作用(哪位朋友知道如何解决这个问题?)!

另外,.NET Framework 1.2 Runtime也可以通过安装Microsoft Yukon(Beta)自动得到。

Ok,言归正传,以下部分就是我的方案。

l 我的方案

上次的讨论主要集中在现有的技术,同时,也对不同技术在实现DAL时的差异做了一些分析,综合下来,无非就是这么几种:

(1) ADO.NET

ADO.NET是当前阶段使用.NET进行DAL开发的基本方式,这里的DAL,也包括了对ADO.NET进行封装后提供更简单调用的各类实现,经典例子如:Duwamish,PetShop等;

(2) O/R Mapping

由于.NET Framework 1.2/2.0还未正式Release,包含其中的ObjectSpaces技术暂时还未能成为在.NET下进行DAL开发的首选武器,但是,随着各类ORM Framework的逐渐成熟以及一些开发厂商的不断努力,这方面正呈现出茁壮成长的势头;

(3) X/Y Mapping

这里的X/Y Mapping是指除了上述O/R Mapping之外的其它各类Data Mapping,如:XML to Relation Mapping,Relation to XML Mapping,Object to XML Mapping等,这部分内容不是本文重点,作者将另辟专文讨论;

(4) Distributed Process

严格来说,这个并不是真正意义上的DAL技术,充其量只算锦上添花。不过,正因为考虑到DAL分布式处理的可能性,作者在自己的方案中将其单独归类,并不将其作为DAL的主要特性去实现。这方面的技术大家早已耳熟能详:.NET Remoting,WebServices。

以下,作者将给出一个自己的解决方案,通过实例,和大家一起探讨一下.NET下的DAL实现技术。

u 综合现有的技术

1. 概述

说是解决方案,其实也就是一个“大杂烩”,作者希望通过综合现有的.NET DAL技术来达到Generic目的,免去了为不同项目反复编写DAL的无尽痛苦L,虽然绝对不是银弹,总也想为广大(我也是“受害者”之一J)DAL工程师们带来一点点的改善。除此之外,Ease of Use也是这个解决方案必须考虑的另一难题!

为简单起见,以下将作者的解决方案简称为:DAF(Data Access Facade) Solution。

总的来说,就作者个人观点,DAL Generic有两方面需要我们重点考虑:

(1) 接口一致性:这个大部分Solution都能满足,但有一点比较讨厌,就是Data Entity的设计!这是一个很难Generic的家伙,经常让人顾此失彼L

(2) 存储无关性:Database方面可以通过Provider Factory实现,但XML与Database的混合存储模式就比较麻烦了!随着XML在应用中的逐渐普及(Yukon甚至将其集成到了Database Table Column中),DAL将不可避免地与它产生交互L(当然了,还有种变相的做法也可以解决这个问题:将所有XML问题统统隔离在DAL之外J)

下一段:http://www.csdn.net/develop/Read_Article.asp?id=27544

时间: 2024-12-07 14:13:12

实战 .Net 数据访问层 - 1的相关文章

实战 .Net 数据访问层 - 23

访问|数据 u 使用现成的框架 Ø 首选当然是.NET Framework即将正式推出的ObjectSpaces! Ø 如果希望Total Solution,Borland ECO就是最佳选择! Ø 其它 n 开源项目推荐使用OPF(国外) n 商业产品推荐使用Grove(国内) u 设计自己的持久层 Ø 如果希望自己设计轮子,那么,最好的参考资料莫过于这篇文章:http://www.ambysoft.com/persistenceLayer.pdf Ø 它山之石,可以攻玉 此处之它山,非J2E

实战 .Net 数据访问层 - 5

访问|数据 代码4:我的Data Entity – 2,Framework中的Data Entity // DafBase:提供大部分应用程序所需的基本Data Entity支持, // 包括Collection,ADO.NET [Serializable()] public abstract class DefBase : IList, IDictionary { protected internal string _typeEntity = EntityType.OBJECT; // Col

实战 .Net 数据访问层 - 11

访问|数据 4. Data Access Logic 讨论Data Access Logic(为了不和Data Access Layer混淆,文中 所有涉及Data Access Logic的部分将全部使用全称描述,DAL仅指Data Access Layer)前,让我们先看一看它的结构示意图: 咦!怎么回事?看上去长得与DAF非常相似嘛!难道这就是作 者"不辞辛劳"单独开辟一个小节来进行"大肆宣传"的Data Access Logic吗? 没错!这就是Data A

实战 .Net 数据访问层 - 12

访问|数据 从这个DalBase很容易看出,Framework Level的支持主要集中 在Cache Management和Distributed Process上面,这也几乎是所 有Data Access Logic都不得不考虑的现实问题(可能在实际项目中, Data Access Logic Level的Distributed Process需求不会很多,大部分 都在Business Logic中直接解决了)! 以下,就让我们看看制造一个真正的Data Access Logic是多么的 方

实战 .Net 数据访问层 - 22

访问|数据 Ok,在结束整个"我的方案"之前,作者最后"献上"一段代 码(是不是有点晕了?),希望能为您的DAF之旅划上一个圆满的句号J 代码17:通过DAF更新数据 // 创建Customer数据访问对象 CustomerDaf daf = new CustomerDaf(); // 创建Customer数据实体对象,设置对象字段值 Customer cust_1 = new Customer(); cust_1.Id = "ALFKI"; c

实战 .Net 数据访问层 - 10

访问|数据 以下是DAF的结构示意图: 是不是看上去还比较简单? 根据以往的经验判断,在这种继承模式下,主要的开发工作全部集中到了DafBase和MyDaf身上,CustomerDaf的任务相对轻松,数据校验或者转换处理也并不是每个方法都需要的J 那么,DAF既然号称Façade,除了满足Façade之必要条件,还要起很好的表率作用,为上面的Data Entity Façade和下面的Data Access Layer作出一个榜样(也是一个桥梁),以下就是作者总结出的4大要素: (1) 所有的数

实战 .Net 数据访问层 - 18

访问|数据 谈了些实现问题,来说说几个题外话: (1) 性能问题:Cache Management能显著提高数据访问效率,但对内存的要求比较高,尤其是在Web Application或Remoting Server这种应用环境下! 所以,这就要求我们应该将"钱"用在"刀刃"上(对内存毫不在乎者除外J),不能乱花钱! 一般,对于系统数据(如:应用 / 模块,组 / 用户 / 权限等)或Lookup Data(如:婚姻状况列举 / 政治面貌列举等),可以考虑放入Cach

实战 .Net 数据访问层 - 16

访问|数据 5. Cache Management 首先说明一点,之所以将Cache Management单列出来,就 是为了要说明数据缓存的重要性!在很多时候,这比撰写Data Access Logic更让人费心,也更令人难以把握. 作者的这个Cache Management实现了进行Data Cache时所 必须考虑的几个问题,虽然还并不完善,但也可在实战中运用了! 以下,就是它的结构示意图: 从图中,可以很明显地看到,这个Cache Management方案 主要由3部分组成:Manage

实战 .Net 数据访问层 - 19

访问|数据 6. ASPECT AOP(Aspect Oriented Programming)可能是最近几年被挖掘出 来的最具震撼力的技术之一,作者并不打算在此花什么篇幅介绍它(网上资料已多如牛毛),只是希望借用其ASPECT概念来说明几个设计Data Access Layer时必须考虑的问题(也是在进行系统架构设计前不得不考虑的几个重要因素!): (1) Security 把它排在ASPECT首位相信大家没什么疑义吧! 虽然,Business Logic已为我们搞定了太多的Security