代码改变世界

关于数据访问模式(五)—— Layers模式

2005-07-31 23:50 FantasySoft 阅读(...) 评论(...) 编辑 收藏

        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]  参考书籍:《数据访问模式——面向对象应用中的数据库交互》