关于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 |