从这个 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 要求的所有功能（比如：上面的代码 1