实战 .Net 数据访问层 - 12

访问|数据

从这个DalBase很容易看出,Framework Level的支持主要集中

在Cache Management和Distributed Process上面,这也几乎是所

有Data Access Logic都不得不考虑的现实问题(可能在实际项目中,

Data Access Logic Level的Distributed Process需求不会很多,大部分

都在Business Logic中直接解决了)!

以下,就让我们看看制造一个真正的Data Access Logic是多么的

方便J

代码10:打造自己的Data Access Logic

// MyDal:提供当前应用程序所需的数据访问支持,从DalBase继承

public class MyDal : DalBase

{

public MyDal() { }

}

// CustomerDal_ADOX:提供使用传统ADO.NET进行数据访问的支持,从MyDal继承

class CustomerDal_ADOX : MyDal

{

public CustomerDal_ADOX() { }

protected internal MyCustomer GetCustomerById(string strId)

{...}

protected internal void UpdateCustomer(MyCustomer cust)

{...}

...

}

// CustomerDal_ORM:提供使用O/R Mapping进行数据访问的支持,从MyDal继承

class CustomerDal_ORM : MyDal

{

public CustomerDal_ORM() { }

protected internal MyCustomer GetAllCustomers()

{...}

protected internal void UpdateCustomers (MyCustomer cust)

{...}

...

}

上面代码中的MyDal并未真正实现什么操作,纯粹为了扩展而设置,用户也可以类似DAF中那样,绕过MyDal这层,直接让

CustomerDal_ADOX或CustomerDal_ORM从DalBase继承,这会使

我们的系统结构显得更加简洁明了。

从上面的代码中,我们很容易地发现,所有Data Access Logic

方法全部被声明为protected internal,why?

当然还是因为那个“可恨的”DAF!接口一致性的代价就在这里

体现出来了(真可恶啊,前面说了那么多天花乱坠的原因,到了这

么后面才谈DAF的缺点J)!

虽然被“剥夺”了在代码中直接点出Data Access Logic方法的“快

感”,但如果您真的非常需要这么做(强烈不推荐J),还是有如下3

个办法的(当然了,作者是非常不希望您就这么将DAF打入冷宫,

毕竟也花了好多心血和篇幅大大的宣传了一番啊J):

(1) 将您的访问代码与Data Access Logic编译进一个Assembly中,这样,神奇的internal就会使您心想事成(DAF、Data Access Logic同属Data Access模块,一般打进一个Assembly编译,所以天然具有了internal魔力J)!付出的代价则是:您不得不将Business Logic(或其它调用模块)与Data Access放在同一个Layer中L,失去了一个良好设计的系统所应有的层次感和灵活性!

(2) internal是深具.NET特色的3大惯用法宝之一(提醒:请勿滥用L),另一武器当然就是我们的Reflection啦!

Ok,也不用您自己出手,系统早已准备了Helper供您享用:

public static object InvokeMethod(

Type type, string method, object[] paramsValue)

(3) 如果手痒或嫌系统提供的方法不好用,那就只有自己出马了,相信,您对Reflection也早已滚瓜烂熟,三下五除二就能轻松拿下了(不过,作者还是要提醒一句:千万不要滥用!protected的设计意图非常明确,慎之慎之L)!

说了那么多,还是一句话:快用DAF吧,它(也)会让您快乐

的J!

不过,有一个问题也需要向大家交待清楚:这里,作者为何没有

使用Factory Pattern来构造不同的Data Access Logic实现(不使用

Factory的代价是需要提供到method级别的大量配置信息,确实有点

麻烦L)?

这主要基于2个考虑:

(1) Data Access Logic不一定会遵守DAF的一致性原则,Data Entity也不尽相同(对于遗留Data Access Logic代码,甚至连参数都有可能存在差异),这种情况下,定义一个Generic Interface有一定困难;

(2) 并不是每个Data Access Logic都会实现DAF要求的所有功能(比如:上面的代码10中,就是通过CustomerDal_ADOX与CustomerDal_ORM这两个Data Access Logic来共同构筑起面向Customer进行数据访问的全部功能。试想一下,如果采用了Factory,岂不是“与我何干”的东东也要被迫全盘接受?而且,即使写个空方法接受了,又如何实现对其它Data Access Logic的真正调用(写这样的Factory可真有点难度啊?

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

时间: 2024-09-03 22:28:12

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

实战 .Net 数据访问层 - 1

访问|数据 实战 .Net 数据访问层 l 特别说明 本篇实战共分23段,非作者有意如此,乃受CSDN发表文章之64K所限. 虽然有几段根本没有达到64K,但估计是HTML Source超过了这个范 围,所以也不得不单独分段(大都是源代码),请大家谅解. 如果有朋友需要完整文档,请发邮件给我: mailto:xuefeng.zhang@bearingpoint.com l 引言 这次的讨论是上一部分"剖析 .Net 下的数据访问层技术"的一个续,但也可独立成章,为突出主题,作者就特意换

实战 .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 数据访问层 - 18

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

实战 .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 数据访问层 - 15

访问|数据 上面的示意图中,步骤7指向的Remoting Server就是Host程序, 而Remoting Server包裹着的RemoteCustomer就是真正提供服务的数 据操作类. 以下所列代码即为该类的部分实现: 代码13:使用Data Access Logic进行Remoting调用 – 3,RemoteCustomer public class RemoteCustomer: MarshalByRefObject { public RemoteCustomer() { } pub

实战 .Net 数据访问层 - 14

访问|数据 代码12:使用Data Access Logic进行Remoting调用 – 2,Remoting访问 class CustomerDal_ORM : MyDal { // 请注意:这个delegate方法被限制为private访问权限 private ArrayList GetAllCustomers_Remoting_delegate() { ArrayList al = null; RemoteCustomer remote = (RemoteCustomer)Activato