从这个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可真有点难度啊？
