** 4. ** ** Data Access Logic **
讨论 Data Access Logic （为了不和 Data Access Layer 混淆，文中
所有涉及 Data Access Logic 的部分将全部使用全称描述， ** DAL ** ** 仅指 ** ** Data Access Layer ** ）前，让我们先看一看它的结构示意图：
咦！怎么回事？看上去长得与 DAF 非常相似嘛！难道这就是作
者“不辞辛劳”单独开辟一个小节来进行“大肆宣传”的 Data Access
Logic 吗？
没错！这就是 Data Access Logic ！它是和 DAF 长得有点像，但
绝对不是孪生兄弟，它所起的作用也和 DAF 完全不同！
首先需要声明的是， Data Access Logic 与 DAF 间的相似性确实
存在，但也就体现在如下两个方面（作者认为这并不是其主要特性）：
（1） 它们都采用了 2 次继承模式；
（2） Data Access Logic 的前两层（ DalBase / MyDal ）作用大致相当于 DAF 中的前两层作用，分别在 Framework Level 和 Application Level 提供一些基础服务。
但是，除此之外，作者需要特别强调的是， Data Access Logic 的
关键特性并不在这前两层（ DAF 则有点不同，它的前两层非常重要），
而是在真正实现了具体 Data Access Logic 的 第 ** 3 ** ** 层 ** 中！
打个简单比方： DAF 有点像 .NET 中的 Interface ，而 Data Access Logic 则更像 Implementation J 。
那么，作者为何不直接将 DAF 声明为 Interface 而令 Data Access Logic 直接继承之呢？到底是什么原因令我们必须将它们严格分开，并在不同的 Layer 中进行处理呢？
其实，原因在上面已经分析了一部分（ DAF 需要确保接口声明一致，数据实体一致，而 Data Access Logic 则无此限制），另一部分原因则在于， DAF 对外需要统一公布所有接口，而 Data Access Logic 则可以相对灵活地进行不同处理。例如：可以将 ADO.NET 相关的数据访问操作集中在一个地方，而 XML 相关的处理放置则可以在另一个地方进行实现（是不是更有利于细化分工 J ）！
还有两种情况可能也需要支持这种变化：
（1） 当前版本中，我们使用了某种方法实现 Data Access Logic ，例如： O/R Mapping ，可是在后续版本中，由于某些原因（性能 / 复杂度），我们需要改用 DataSet 方式进行交互，这时候，我们为 DataSet 撰写的新方法就可以非常方便的替换现有的 O/R Mapping 方法（只要修改一下配置信息），而对外接口（ DAF ）则根本不必修改（当然了，原来针对 O/R Mapping 返回数据进行处理的那些代码是必须要修改的，但这并不会破坏 Cross Layer 间的接口一致性）！
（2） 系统中可能会存在一些遗留 Data Access Logic 代码，这部分东东弃之可惜，食之则余香依旧，怎么办呢？很简单，交给 DAF 处理吧！我们可以单独建立一个 Data Access Logic 模块（例如： CustomerDal_LEGACY ）专门包含这部分代码，然后，在 DAF 中使用 ** Adapter ** Pattern 将其统统归入门下（当然了，也可以在这个专用 Data Access Logic 模块中直接包装，但作者更喜欢使用 DAF 干这样的杂事 J ）！
Ok ，文字看累了，来段代码瞅瞅：
代码 9 ：掀起 Data Access Logic 的盖头来！
// DalBase ：提供大部分应用程序所需的基本数据访问支持，
// 包括分布式处理，数据缓存支持等 ** **
public class ** DalBase **
{
public ** DalBase ** () { }
protected string GetDistributionType()
{
string strType = null ;
... // 根据当前调用上下文和配置文件得到所需数据
return strType;
}
protected ** CacheParam ** GetCacheParam()
{
** CacheParam ** param = null ;
... // 根据当前调用上下文和配置文件得到所需数据
return param;
}
...
}