关于SSH架构的设想

关于SSH架构的设想

 

目前流行的轻量级J2EE应用的架构比较一致，采用的技术也比较一致，通常使用Spring作为核心，向上整合MVC框架（Struts），向下整合ORM框架（Hibernate）。使用Spring的IoC容器来管理各组件之间的依赖关系，同时用Spring的声明事务负责业务逻辑层的事务管理。

Spring可以很容易的实现AOP，还可以大大降低各业务组件之间的耦合度，对于业务经常变动的应用，是个不错的选择。

Struts易于使用，懂的人很多，这样的程序员很容易找到，不需要花费培训成本。

而Hibernate使用简单，虽然在面对大吞吐量和复杂查询时效里不是很好，但是可以灵活使用，不得以的情况下，通过直接使用JDBC 也可以大幅提高性能。

       但在固定的技术组合上，各公司及开发团队有依然可能存在小的变化。下面讨论根据本人的经验及公司实际情况而采取的架构策略：Anemia Domain Model。

       所谓Anemia Domain Object是指Domain类只是单纯的数据类POJO(Plain Old Java Object)，不包含业务逻辑方法，即每个Domain类只包含基本的setter和getter方法。所有的业务逻辑都由业务逻辑组件（ServiceBean）实现，这种Domain Object就是所谓的贫血（anemia）的Domain Object，采用这种Domain Object的架构即所谓的贫血模式。

在贫血模式下，业务逻辑对象封装了全部的业务逻辑方法，Web层仅与业务逻辑组件交互即可，无须访问底层的DAO对象。其分层非常清晰。Domain Object 并不具备领域对象的业务逻辑功能，仅仅是ORM框架持久化所需的POJO，仅是数据载体。这种模型容易理解，开发便捷，但所有的Domain Object并不是完整的Java对象，仅仅是一种类似struct的数据结构。

       贫血模式存在如下缺点：

一、项目需要书写大量的贫血类，当然也可以借助某些工具（Hibernate有）自动生成。

二、 Domain Object的业务逻辑得不到体现。由于业务逻辑对象的复杂度大大增加，许多不应该由业务逻辑对象实现的业务逻辑方法，完全由业务逻辑对象实现，从而使业务逻辑对象的实现类变得相当臃肿。

三、很多直接、简单的CRUD（添删改查）操作需要经过业务逻辑层从DAO对象穿透到WEB层，代码虽然不多，但显得很繁琐、会降低性能及程序员生产率。

优点是：开发简单、分层清晰、架构明晰且不易混淆；所有的依赖都是单向依赖，解耦优秀。适合于整体水平不高的开发团队。

下面指出几个要特别注意的地方：

1、  DAO对象不应当出现在WEB层；

2、  对业务层对象的访问在ActionBean中得到，但在ActionBean中只能放一个业务层对象，即一个ActionBean对应一个ServiceBean，不能访问多个；并且尽量只调用ServiceBean的一个方法来完成业务层操作；

3、  一个业务层对象可以调用多个DAO对象，需要在4中控制DAO对象的事务处理；业务层对象尽量不要调用其他业务层对象（AOP对象除外，如log4j对象或者其他应用中自已定义的AOP）；

4、  事务处理在业务逻辑层中，使用了Spring针对Hibernate3给出的HibernateTransactionManager，它提供了Hibernate的本地事务管理策略  

界面（JSP）

控制器（Struts）

业务逻辑1

DAO1

DAO2

DAO3

DAO4

DAO5

业务逻辑2

业务逻辑3

数据库

FormBean

DomainBean

转换

转换

关系表

Spring