实战 .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