访问|数据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则更像ImplementationJ。

那么，作者为何不直接将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;

}

...

}