基于SSH开发架构的重新分层/SSH思想之我见

 

基于SSH开发架构的重新分层

    现代的企业开发中，越来越多地引入了多层架构设计模式。Struts+Spring+Hibernate (一下简称为SSH)就是其中之一，SSH架构是当前非常火的架构，很多金融、电信项目，大型门户网站均选择该架构作为业务支撑架构，开发流程也已经非常成熟。但是该结构开发起来，依旧存在一些问题。分析这些问题，得先从SSH架构的组成说起。

    SSH为Struts+spring+hibernate的组成方式，Struts实现MVC，Spring负责架构的结合，Hibernate进行数据的持久化。通常其分层开发的结构图(以一个业务新增为例)如下：

这样的结构，满足了一般的业务需要，但是对于当前日益复杂化的WEB2.0的开发，却存在不少问题，归纳起来主要有以下几点的不足：

 

    A)DAO和服务层容易出现职责不明，由于按照MVC逻辑，业务代码应该写在Struts Action里，但是其事务的提供，却是配置在Service层。为了一组在逻辑上完整的数据操作业务逻辑，需要涉及两个层（Serveice、Action）来进行编写，遇到判断的情况下，为了保证完整的事务操作，则需要将业务代码移到Service层完成，而通常习惯了在Struts Action里调用多次Service而产生多个事务而在出现Exception时导致出错时操作之前调用的Service事务的业务数据没有回滚。

 

    B)当需要返回的数据供AJAX使用，操作JSON或XML的的大量使用时。开发起来会很费力，一段同样的业务代码，为了使用AJAX和XML可能需要重新编写一次，或者在同一个ACTION里通过标志来判断，对分层结构造成了比较糟糕的破坏。如果设计得不好，为了使用JSON和XML还得额外增加大量的配置，严重降低了开发效率。

 

    因此，为了克服这些缺点，本人对于SSH架构，进行了实现了重新的分层，共享了业务代码。简化了开发、增强了与AJAX技术、MXL技术的结合。提供了一种更高效的开发模式。

 

其开发的结构图如下：

 

    看到这个架构图有人可能会问，Struts Action类的编写去哪了呢？答案正是这个架构的优点，由于业务代码统一实现IbusinessService接口，使得只需要相对固定的几个Struts Action类调用Service层的方法，便可以完成工作。包括JSON格式输出，XML输出及WebService输出均调用Service层方法来完成功能。这样便实现了业务代码的分离，以及与前端框架的极大解耦.

SSH思想之我见

SSH就是struts1.0与Hibernate由spring解耦合。

          SSH分三层，web层（struts），业务逻辑层，数据库操作层（hibernate）。SSH是J2EE中应用最为广泛的系统级开发框架。

因为它的易于维护和拓展，使得SSH得到广泛的应用。

          SSH的精髓在于spring的管理。

******************************************************************

          常见的SSH层一般分为7层：

          dao层（数据库接口），daoimpl层（数据库操作实现类），vo层（POJO类，数据库实体类），service层（业务逻辑层接口），

serviceimpl层（业务逻辑实现层），action层（web逻辑处理层），form（表单处理层）。

          struts开发项目由来已久，可以说是实现MVC的最早的完善框架。但是技术一直在发展与进步，以至于现在渐渐的已经被更实用的

框架取代，例如struts2（webwook+struts的结合），JSF......之类，这些框架会更好使，更加合理，开发会更easy。但是如果说发展的

成熟度，其实这些新兴框架，也足够完善。起码struts2已经可以很好的开发。从而也就有了我之前的随笔《struts2+spring+Hibernate搭建全解》

。其实前段用哪个框架也不是固定的。

          Hibernate是数据库持久化的框架，是我们从以往的操作数据库转变为操作对象。更利于面向对象编程。而且也对数据库操作进行了封装。

优化了sql语句，异常抛出，开闭连接等等。可以说是非常完善的底层框架。spring对Hibernate注入的操作和方法。也更加方便了操作。但是我并

不主张，让spring过多的注入Hibernate，因为spring的诞生就是解耦的。使web层，与数据库底层操作分离。这样把业务逻辑分离出来。便于扩展

新功能或删除不用的功能，或着移植代码。是在MVC模式把美工（UI设计）和后台编程分离来后的又一大革新。使程序员面向接口编程。把后台的

开发也完美的分离。对于小型的项目来说也许并不意味着什么。但是对于中大型项目来说，节省了大把的开发成本。

          spring就是SSH的画龙点睛之处。spring的精华在于反射机制。偶不得不赞叹

spring的两个核心AOP（面向切面编程），IOC（依赖注入）十分的帅。这两个思想，体现在spring的XML配置文件之中。 其中的依赖注入

是由Bean实现，从而实现面向切面编程，事务的管理。ACEGI（security）（权限验证框架，有待偶的进一步研究）框架中体现就明显。

******************************************************************

废话也不想多说，直接说SSH思想和特点：

1.除了实例化POJO对象需要new对象以外实现impl不再需要new对象，一切都是getBean读取配置文件spring配置文件。

2. 解耦web层与数据库操作层。

3. 利用反射动态获取所有类信息。

4. 对数据库的操作对象化，除了取出单独字段和查询外，尽量使用数据库实例化对象，尽量不使用HQL语句。

******************************************************************

我在刚开始SSH搭建的过程中总是遇到空指针。这就是由于我的思想还停留在struts+Hibernate层面，没有理解SSH的思想。

这样的话，我的这路实现操作与spring根本不同路，而Hibernate又是通过spring配置的。所以当然数据库操作会报空指针的错。

这个困扰我很久。然后就是什么样的分层才是最帅的最合理的。

最终借鉴网上的一些思想和师兄的开发心得，我终于有了自己的实现分层思路。

******************************************************************

最初是打算一个DAO包括所有数据库操作接口。一共20个接口：这套接口是非常成熟且实用的。包括：

增删改查，动态查询，高级搜索，分页实现，动态分页。 这是传说中的BaseDao（当然你也可以叫别的名）。

然后一个BaseDaoImpl实现类。接着是业务逻辑层，和web层。除了这个基类Dao外不再有其他的数据库操作类。

这样业务逻辑层就变得臃肿。其中既有HQL，又有对象的实例化。但是我的想法是本着分离两层，以后功能扩展修改

直接通过修改业务逻辑层一个层和web层。这样就可以少维护一个层。但是后来师兄的心得使我改变了想法。

******************************************************************

师兄的项目是除了BaseDao接口外又新建了其他的数据库操作接口。然后全部实例化操作。让这些子接口继承BaseDao接口，

，但是这样就和我一开始的想法有点冲突。但是实事证明，这样有好处。就是HQL，对象实例化都在DaoImpl里，业务层专注实现

业务，根本不考虑底层操作。也没有乱七八糟的HQL语句。如果修改业务，那么DaoImpl也不用动。毕竟这些方法也不会占几百MB

代码的项目多大地儿。留着呗，说不好以后有用呢。感觉这个方法就是我假期做东西的思路。

******************************************************************

最终我决定使用一个折中的方案，一个BaseDao，多个DaoImpl实现类。因为Dao子接口基本和service层接口一致，所以如果

再写一遍，总觉得是多余。所以就不写了，这套DaoImpl注入BaseDao的实现类方法，并且自己也继承HibernateDaoSupport，

以方便使用泛型或者更灵活的操作数据库对象。一个BaseAction封装并重用getBean等spring与struts的action整合的类。

一个BaseService接口当然也不是必须的，负责业务实现中的对象创建与获取，一个BaseServiceImpl也不是必须的，实例化BaseService

接口。

******************************************************************