关于数据访问模式（五）—— Layers模式

        Layers(层)模式，我想大家应该都不会陌生了。不管是硬件驱动程序、TCP/IP协议，还是J2EE应用软件的架构，层的应用几乎无所不在。我们专注到Web Application上来，三层以及多层结构的应用更是遍地开花。那么，层的强大之处在哪里呢？我们是否真的了解层的划分呢？
        我们面对一个复杂问题的时候，都会想着将这个问题化整为零，分为一个个子问题，然后逐个击破。相应的，处理这样复杂问题的软件也会进行划分。通常我们将处理这些子问题的程序称为component(组件)。那么组件或者组件的集合是否就可以称为层呢？在回答这个问题之前，我们先来了解一个概念——Orthogonal Component (正交组件)^[1]。
        所谓正交组件，就是处理完全不相交问题的软件组件。当你打算将层模式应用到软件设计的时候，就要花心思去搜寻问题中那些不相交的问题，从而为这些问题建立相应的正交组件。只有正交组件之间的关系才能称为层。这样说，似乎有点玄乎，我也说得有点晕眩了。还是说说现实中的例子吧，其实在之前的Post中有提到的Data Accessor和Active Domain Object就可以称作正交组件，Data Accessor主要负责数据库物理访问的细节，并为Active Domain Object提供相应的接口；而Active Domain Object则是为应用程序提供与Domain Object相关的逻辑操作，同时它是利用了Data Accessor提供的抽象接口来完成自己的具体实现的，它对Data Accessor的具体实现是一无所知的。正是基于这样的条件，Data Accessor和Active Domain Object就成为正交组件，并且形成了不同的层，如下图所示：

        层模式中的某一层实现并非是最困难的，难就难在层的划分，以下的几个方面都是十分适合在单独层中实现的：
        1、数据访问细节：例如Data Accessor；
        2、域对象映射：例如Active Domain Object；
        3、缓存：例如数据缓存，statement缓存； 
        4、数据源分布；
        5、权限管理；
        6、资源管理：例如连接池；
        随着层次划分的增多，随之而来的就是复杂性的提高，而且层初始化的成本也会相应的增加。恰到好处的层次划分在层模式的应用尤其重要。
  
        [1]  Orthogonal Component
        [2]  参考书籍：《数据访问模式——面向对象应用中的数据库交互》