表模块模式（Table Module）

    (大量参考PoEAA...-_-...)

    最近网上看到这样的帖子<<谁能告诉我Hibernate有何优秀之处>> 作者给出了对hibernate在实现orm的诸多不满和怀疑。而且很多开发人员都有着这样疑问，“怎么这个流行东东，我用起来就是不顺手呢？”，“或许这个东东只是用来吹牛的…”。然而，这或许很可能是因为，你习惯的架构模式开发策略并不适合使用orm这种持久化模式。用了反而是加大复杂度降低性能和效率。比如，用惯了resultset，喜欢把resultset放在表示层作为展示的数据结构的人。这样的开发人员因为习惯了二维表为核心进行开发，对于Hibernate这样的orm工具根本就没办法了解其优势了。但是这并不是说这种以二维表的架构模式就比较差了，只是不同的模式有不同的优缺点就看所在的应用是否适合使用了。或许你就一直在使用这样的模式在开发应用，自己还没有意识到（甚至一直以为这样的方式可以适应任何应用，:-）。反而被其他架构模式中才会用到的框架搞的晕头转向甚至被误导。事实上，像前面提到的以二维表为核心的架构被称之为”表模块”架构(设计)模式。

       何为“表模块”(table module)？“处理某一个数据库表、视图或虚拟表中所有行为的业务逻辑组成的一个实例”。最初，我就是从马丁同学的POEAA中得到的这个定义。在书中他被定义在DomainLogic 层次或者该层次的一部分，DomainLogic也就是其他架构模型中的BizLogic层。与该模式相对应个还有完成相似功能的DomainModel以及TransactionScript模式。该层次的职责是专门处理业务逻辑。

       简单的讲，所谓“表模块”就是以一个类对应数据库中一个表（视图）的数据来组织业务逻辑。从设计层次表妙面上看这种结构很像经典OO模型，同样是以不同对象对应不同逻辑。但是，它与领域建模不同之处在于，它的对象并不表示一个问题领域对象在软件系统中的映射。而是表示对一组数据的处理逻辑，而通常这组数据的结构是重数据库表或试图上的二维数据结构。当然也可以来自其他集成部分，比如返回两位数据结构的webservice。

       这里给出个比较形象的例子：

<!----><!---->
<!---->

       （上图）感觉像比较标准的OO吧，好象一个Contract的对象表示合同，而Product表示产品，还有他们之间的关联关系。但是其实现实给出几个方法的时候就看出区别了。Product内部的数据其实就是一个两位结构的rowset。而不像真正的领域模型分析出来的表示一个Product的数据，Contract也是如此。

<!----><!---->
<!---->

       你会发现tableModule的类中一个对象其实对应一个表的数据，其拥有的操作也有很多是多数据记录的。多数据记录的操作在真正的领域中往往应该放在类似Manager这样的实体中，而不是业务实体本身。

       使用这种模式实现的业务逻辑层不像领域模型模式可以适应搞复杂度的逻辑。但是由于它更亲近于数据持久的二维表，没有像领域模型那样需要复杂的ORM支持。书对于数据驱动的应用或模块非常适合。POEAA中也已经给出了这种bizLogic最有效的持久层实现，就是table getway，当然也可以使用其他的方式比如“查询工厂”。

       事实上，最多使用这种模式的情况是当后台数据源大部分都是一种两维甚至多维数据结构的时候进行。比如一个极端的例子（几乎没有业务），一个应用的复杂查询模块，这种模块就是一个查询模型加上一组对数据进行排列统计过滤的TableModule。

       

<!----><!----><!---->

       表模块还具有很多特点：处理的二维数据表将成为代码的核心部分。所以，是否使用tableModule还会取决于整个应用的其他部分是否对这种二维表提供强大的支持。（如上图）

       优点：持久层架构简单，在复杂度大的以数据为核心的应用中开发效率极高。而且表模块能够识别的table越多，能够处理table的组建工具越强，这种模型的能力越强。

       缺点：不能适应复杂的应用逻辑，或者与表结构差别较大的应用逻辑。由于没有对内部的两位数据表（table）进行有效标识的方式（比如，无法快速简单的确定使用table是否是需要的数据内容），对于大量细颗粒的逻辑会增加其复杂度。

       其实java中的 rowset/jdbc resultset，.net中的 dateSet/dataTable都属于表模块操作的二维表。但是，由于.net在GUI层面以及持久化层面对他自己的”二维表”的强大支持使得 TableModule几乎成为MS.Net上的首选模式。这也就可以解释了，许多.net开发人员一直抱怨，看到dataset/dataTable泛滥，甚至在WebService中也是这样。而java中却有所不同，虽然有持久化用到的jdbc/resultSet的支持（事实上jdbc/ado 给出的接口都只直接适合TableModule。），然而其他方面就少得可怜了。所以，使用java还是以其他的bizLogic架构模式为好。除非你的逻辑真的很简单，简单到把resultSet放在jsp中都不会造成逻辑混乱。又或者你能够自己提供一套完整的 rowset组建框架。