如何在struts+spring+hibernate的框架下构建低耦合高内聚的软件

一.问题的提出

我常常在思考一个问题，我们如何能设计出高水平、高质量的软件出来。怎样是高水平、高质量的软件？它应当是易于维护、易于适应变更、可重用性好的一个系统。如何做到这一点呢？答案当然是“低耦合、高内聚”了。低耦合就是软件在构造的时候，各个模块、各个功能、各个类都不会过度依赖于它周围的环境。只有这样，才能使我们的模块（功能、类）在周围发生变更时不受影响，做到易于维护和易于适应变更。正因为如此，也使它更易于重用到其它功能类似的环境中，提高了重用性。高内聚则使软件中的各个模块（功能、类）能够各尽其能而又充分合作，也就是对于软件问题空间中需求的各个功能，系统可以合理地把它分配给各个模块（功能、类）来共同完成，而不是一个或几个八面玲珑、包打天下的超级类一个人完成。而对于该系统中的某一个模块（功能、类），具有自己高度相关的职责，即该职责中的几个任务是高度相关的。每一个模块（功能、类）都决不去完成与自己无关职责的任务。

那么怎样能构造一个低耦合、高内聚的系统呢，时下最流行的框架结构之一的struts+spring+hibernate为我们提供了方便。使用struts我们可以应用MVC模型，使页面展现与业务逻辑分离，做到了页面展现与业务逻辑的低耦合。当我们的页面展现需要变更时，我们只需要修改我们的页面，而不影响我们的业务逻辑；同样，我们的业务逻辑需要变更的时候，我们只需要修改我们的java程序，与我们的页面无关。使用spring我们运用IoC（反向控制），降低了业务逻辑中各个类的相互依赖。假如类A因为需要功能F而调用类B，在通常的情况下类A需要引用类B，因而类A就依赖于类B了，也就是说当类B不存在的时候类A就无法使用了。使用了IoC，类A调用的仅仅是实现了功能F的接口的某个类，这个类可能是类B，也可能是另一个类C，由spring的配置文件来决定。这样，类A就不再依赖于类B了，耦合度降低，重用性提高了。使用hibernate则是使我们的业务逻辑与数据持久化分离，也就是与将数据存储到数据库的操作分离。我们在业务逻辑中只需要将数据放到值对象中，然后交给hibernate，或者从hibernate那里得到值对象。至于用Oracle、MySQL还是SQL Server，如何执行的操作，与我无关。

然而我要说的是，即使我们使用了struts+spring+hibernate框架构建我们的软件，就可以做到“低耦合、高内聚”了吗？我认为这是远远不够的！我认为我们在使用struts+spring+hibernate框架的时候常常会有以下几个问题值得改进。

二.分析与解决

1.编写DAO的时候不要直接去使用hibernate或spring对hibernate的支持。

现在我们在编写DAO的时候普遍都是直接继承spring对hibernate的封装类HibernateDaoSupport，然后使用该类提供的诸如saveOrUpdate(), saveOrUpdateCopy(), find()等等。另外，在使用excute()方法实现一些更复杂的hibernate功能的时候还会使用hibernate的类，诸如Query, Session, Type等。这样直接使用spring和hibernate的类存在的问题在于，你的代码将不得不依赖与spring和hibernate的某个版本。比如说，现在hibernate3出来了，改动挺大，实际上最要命的是包结构，hibernate2的包结构是net.sf.hibernate.*，然而hibernate3是org.hibernate.*。同样，spring为了支持hibernate3，包名也改为org.springframework.orm.hibernate3.*。假如，你现在新开发一个项目，这没什么关系，如果是升级一个项目问题就来了。如果你希望将你的一个项目从hibernate2升级为hibernate3，你不得不修改DAO中所有对hibernate和spring-hibernate的引用。如果你的代码中出现hibernate2与hibernate3不兼容的方法和类，比如saveOrUpdateCopy()（在hibernate3中已经没有了）,你还将不得不改写。那么你可能会说，我不会这样升级。如果你的软件生命周期有好多年，hibernate升级到4，升级到5，你还是依然使用hibernate2？如果你以这种方式开发一个平台，你能要求所有使用你平台的软件项目都只能使用hibernate2？更进一步说，我现在开发一个产品，今后的客户将是成千上万。经过1、2年我需要升级了，这时我的升级包有几十M，几乎把所有的DAO都换了个遍，这样的升级无异于重装。也许，有人会提出另一个方案，在HibernateDaoSupport与DAO中间增加了一个基础类，这样将基础类中的org.springframework.orm.hibernate.support.HibernateDaoSupport，改为了org.springframework.orm.hibernate3.support.HibernateDaoSupport，这样其下面继承的DAO就不用改动了。然而在源码上是小小的改动，但对于类来说，两个不同版本的HibernateDaoSupport其相关的属性和方法还是有不少变化，那么在基础类重新编译的同时，你的继承类重新编译否。既然已经重新编译了，因此你的所有DAO在升级的时候依然要打入升级包，问题依然存在。

以上问题，究其原因，是我们项目中的DAO依赖于hibernate和spring，因为我们对它们的使用是继承，是一种很强的关联，就是一种依赖。我们只需要稍微进行一些调整，就可以解决这个问题，那就是不使用直接继承，而使用接口进行分离。可以使用Façade模式，先建立一个叫BasicDao的基础类，从名称我们可以看出，它是所有DAO的基础类，实现DAO操作所需的所有诸如save()、delete()、load()、query()等方法，除了一些基本的方法，诸如翻页查询、getCount、解析查询条件形成HQL语句等功能也在这里实现，但是不要使用与hibernate或spring有关的任何方法和类。同时，BasicDao调用一个叫DaoSupport的接口，DaoSupport的接口则是提供持久化所需的基本方法，最原始的元素。然后，我为DaoSupport接口提供各种不同的实现，比如hibernate2的实现DaoSupportHibernateImp、hibernate3的实现DaoSupportHibernate3Imp，整个结构如下图所示。BasicDao可以使用hibernate或spring提供的方法，但是不是直接使用，而是通过调用DaoSupport的实现类来使用。然而BasicDao到底是使用的那个实现类，我们通过spring的IoC，通过配置文件来决定到底使用哪个实现。同时，BasicDao也不要使用诸如SpringContext的类来实现IoC，而是通过建立setDaoSupport()和getDaoSupport()方法，然后在spring配置文件中建立引用。


2.编写Action的时候不要直接使用spring和spring的继承类

前面我说了应当避免DAO引用spring或hibernate及其继承类。同样的事情也发生在Action中。由于Action通常不纳入spring的管理，因此Action在通过spring调用某个BUS的时候，往往是去引用一个叫SpringContext的类（spring的类ContextLoaderServlet的继承类），然后使用它的getBean()方法。如此的使用，我们的Action将依赖与spring。我们同样可以使用一个叫BasicAction的父类，然后用一个接口来隔离spring。由于Action通常不纳入spring的管理，我们通过一个*.property的配置文件来决定接口到底调用哪个实现类。这样的结构的另一个好处是，我们还可以将所有Action都必须使用的诸如写日志、用户校验、异常处理都放在父类BasicAction中，提高系统的可维护性。

3.当BUS需要获取别的模块的数据的时候，不要直接去使用该模块的DAO

我举一个简单的例子：我需要设计一个软件评审的管理软件，该软件分为评审组织者制订评审计划、评审者分别填写评审表后由评审组织者汇总评审表、评审组织者制作评审报告。这是一个非常简单的项目，分成了三个人来完成。但是项目进行快结束的时候却出现了问题。填写评审表需要获得评审计划中的一些数据，制作评审报告的数据来源于评审表。项目组在开始编程前先开了一次会，大家约定好了各个部分的数据格式及其规则，然后开始工作。然而数天后项目组把各个模块整合以后发现，系统根本跑不起来，为什么呢？设计评审计划的人发现，所有评审计划应当按照产品编号来进行管理而不是项目编号。由于这个变更，填写评审表模块在待评审列表中什么都无法显示；同样，设计评审表的人发现，在一个评审计划中评审表与评审者不是一对多的关系，而是一对一的关系，因而修改了这两个表的关联。因为这样，在制作评审报告时就不能正确得到评审表数据。其实一个软件项目在整个进行过程中总是不断变更。我们需要做的不是去抑制这些变更，而应当是通过软件的结构去适应这些变更，即是降低各模块间的依赖（耦合），提高内聚。

拿这个实例来说，当评审表需要调用评审计划的数据的时候，不应当是自己写一个DAO去调用评审计划的数据，而应当是调用评审计划的接口，将这个任务交给评审计划类来完成。当评审报告需要调用评审表的数据的时候，同样应当去调用评审表的接口，由评审表来实现。同时，这种调用应当是去调用BUS层的接口。为什么呢？比如在评审计划中的一个业务逻辑是只有在评审计划发布以后才能制作评审表，那么怎样才是已发布的评审计划呢？这个业务逻辑应当由谁来定义？当然是评审计划。在什么地方定义？当然是BUS而不是DAO，因为DAO仅仅是实现数据的持久化，而BUS才是实现业务逻辑的地方。既然如此，如果评审表去调用评审计划的DAO，那么已发布评审计划的业务逻辑必然包含在了评审表的业务逻辑里了。我们假设有一天，已发布评审计划的业务逻辑发生变更了（实际上这样的会在你毫不经意间就发生了），编写评审计划的人会很快就修改了评审计划的业务实现并且测试通过了。他不知道评审表里也包含了这样的业务逻辑，因而修改后的程序在运行到评审表的时候就很可能会出错。不幸的是，在实际工作中，同样一个业务逻辑可能包含在无数个你可能知道，但你也可能不知道的代码中。这样的结构就是一个不易于维护的差的结构。

三.总结：从技术升级和需求变更两方面适应变化

软件开发专家Alistair Cockburn在《敏捷软件开发》中说过，软件在整个生命周期中变更是无时无刻不发生的。我认为，软件的变更一方面是技术的更新，今天我们使用struts+spring+hibernate，明天呢，我们将使用什么呢？正因为技术变更得太快，我们的系统应当不要太依赖于某个具体的技术或框架，以便于明天的技术更新。同时，来自客户的需求变更也是我们必须面对的另一个压力。一句经典的话是这样描述客户的变更：“当我看到时我的需求就变更了。（I changed just when I saw it.）”过去我们用需求说明书来抑制用户的变更，现在发现不能这样了。敏捷软件开发提出了许多应对用户变更的办法，其中建立低耦合高内聚的软件结构也是办法之一。系统中的所有对象都有自己的明确职责，这个职责应当不多且高度相关。每个对象都应当只完成自己的职责，而把其它的任务交给别人去做。正如我前面提到的例子，评审表对象只完成与评审表相关的操作，而在它需要完成的任务中，需要使用评审计划数据的相关功能，交给评审计划对象去完成，评审表只管调用。这样的构造要求开发者相互协调，彼此多交流，同时，也需要有人来统一规划，站在全局的设计这个系统。通过这些，我们才可以适应变化，提高设计水平。

评论

25 楼 jf_emal 2007-02-09  

呵呵,写的好深啊

24 楼 fangang 2007-02-08  

woodhead 写道

我们就是使用的整个系统一个DAO的方式。当时主要目的倒也不是考虑到Hibernate升级之类的问题，而是想要简化持续层的调用接口（我们的系统用.net开发，很多同事对hibernate不熟悉）,最后效果还不错。还带来了些额外的好处，例如我们在DAO中加入拦截，就能在某些对象发生改变是自动触发一组相关操作。

现在我也在思考整个项目使用一个DAO的方式，这样可以大大简化我们的开发工作。

23 楼 woodhead 2007-02-08  

我们就是使用的整个系统一个DAO的方式。当时主要目的倒也不是考虑到Hibernate升级之类的问题，而是想要简化持续层的调用接口（我们的系统用.net开发，很多同事对hibernate不熟悉）,最后效果还不错。还带来了些额外的好处，例如我们在DAO中加入拦截，就能在某些对象发生改变是自动触发一组相关操作。

22 楼 fangang 2007-02-04  

谢谢downpour。 实际上downpour的疑问也是许多人的疑问，我的许多朋友和同事也常常跟我讨论这个问题。我认为，目前国内的软件开发可以分为几个不同的层次。

1、就是做项目，即为一个或几个特定的客户进行定制开发。这样的开发往往一旦完成就很少或者少量地需要升级。

2、当完成了一个项目以后，有的公司会努力将该软件项目推广到同行业的数家企业中。在把一个项目推广到另一个企业的时候，往往需要在许多地方进行修改和增加新的功能。

3、开发产品。公司根据市场的需要事先开发出一个通用产品，然后努力销售到数百上千家企业。这样的产品往往不断升级，整个软件周期将可能持续十多年。

4、软件开发平台。有的公司为了提高自己的软件开发速度，制作出自己的软件开发平台。在这个软件开发平台使用的数年间，该公司的所有软件项目或产品都将使用这个软件开发平台进行软件开发。

分析这4个层次，第一个层次是我们目前软件行业比较普遍的一种开发模式，它很少需要软件升级，或者升级所需要的修改量不大，因此它不怎么需要我在这篇文章中提出的方案。第二个层次也是比较常见的模式，它需要一些升级维护，但对于本文提出的方案，对于眼光比较长远的公司可能需要，但迫切程度也不是非常大。

对于第三个层次，产品开发的特点是，前期投入大，投向市场的客户群大，软件生命长，软件大规模升级的次数也多。处于这个层次的公司需要考虑的问题就比较多，眼光需要比较长远。他们需要考虑的其中一点就是，当该产品使用数年以后现在需要升级了，这个升级依然使用过去的旧技术，还是与时俱进采用目前的新技术。为了解决这个问题，他们正需要本文提出的方案。

对于第四个层次，一个平台往往需要使用数年，在这数年间将会发生数次技术更新。因此，一个公司在开发自己的平台的时候，必须要考虑技术更新的问题。可以试想，软件开发平台使用数年以后，公司要用平台开发一个新的项目了。这是难道公司因为要使用开发平台就依然沿用数年前的旧技术？他们需要软件开发平台能够经过少量的更新维护就可以应用目前流行的新技术。本文提出的方案正是解决他们的问题的方法之一。

我相信，随着中国软件业的发展和最大利润的追求，会有更多的公司采用第三、第四层次的软件开发。

21 楼 downpour 2007-02-03  

不是很明白。这样就能称之为解耦？

事实上，我们在开发一个J2EE程序的时候，会有很多Assumption。比如说，我们会倾向于使用相对成熟的框架来构建我们的开发。不会轻易的由于使用的Jar包升级而直接更换Jar包。所以楼主所谓的耦合我感觉实在不在我们的讨论范围之内。

如果你真要降低耦合，并不是说你的某些类不应该继承HibernateDAOSupport，而是将Jar包的依赖降低到相对比较轻的程度从而便于单元测试，或者说将Jar包的依赖控制在某个特定的层次（例如DAO层），其他的层次诸如Service层不依赖于这些Jar包而独立存在，这样才能比较轻松地在各种实现上切换。

20 楼 guoxu1983 2007-02-03  

前段时间公司架构师搭出了类似楼主想法的框架，不过，没看懂他那样做的用途，今天得见楼主赐教，恍然大悟。

19 楼 pipi2142001 2007-02-02  

支持原创@_@

18 楼 fangang 2007-02-02  

赞Allen，你这样做也是可以的。我的主要意思就是项目中那些实现具体业务的类不要直接继承和使用spring和hibernate的类和方法，而是通过接口进行隔离。至于如何实现当然是仁者见仁，智者见智了。

17 楼 Allen 2007-02-02  

fangang 写道

Allen 写道

但是采用了“BasicDao基类继承自HibernateDaoSupport”的套路时，DAO层需要更新的也仅仅是BasicDao一个类而已……

谢谢Allen跟我讨论这个问题。我们过去也是使用BasicDao基类直接继承HibernateDaoSupport，起初的想法也是只要更新了BasicDao就可以了，但实际情况却并未所愿，问题就在基类变了，子类是否需要重新编译。如果我们变更了基类，变更后的基类的方法、属性与原基类不同，而我们的子类（不论是直接还是间接）不重新编译，还是使用原来的编译后的文件，那么我们的项目在运行的时候会发生一些莫名其妙的、谁都说不清的问题。正因为如此，不只一个软件设计大师在书中提到，继承是一种强依赖，需要慎用。解决继承的问题的一个比较好的方法就是接口。

这个问题很容易解决，BasicDao（以及其子类们）均实现了某一个接口，DAO们需要使用到的方法在接口中定义好就行了……

16 楼 samkai 2007-02-02  

好啊.不错.顶

15 楼 fangang 2007-02-02  

我按照我的思路写了一个我的实现，放在我的文章中（Spring-Hibernate.rar），水平有限，仅供大家参考。 

14 楼 fangang 2007-02-02  

Allen 写道

但是采用了“BasicDao基类继承自HibernateDaoSupport”的套路时，DAO层需要更新的也仅仅是BasicDao一个类而已……

谢谢Allen跟我讨论这个问题。我们过去也是使用BasicDao基类直接继承HibernateDaoSupport，起初的想法也是只要更新了BasicDao就可以了，但实际情况却并未所愿，问题就在基类变了，子类是否需要重新编译。如果我们变更了基类，变更后的基类的方法、属性与原基类不同，而我们的子类（不论是直接还是间接）不重新编译，还是使用原来的编译后的文件，那么我们的项目在运行的时候会发生一些莫名其妙的、谁都说不清的问题。正因为如此，不只一个软件设计大师在书中提到，继承是一种强依赖，需要慎用。解决继承的问题的一个比较好的方法就是接口。

13 楼 Allen 2007-02-02  

fangang 写道

我们现在要做的是在变化到来的时候，我们能够付出最小的代价适应变化。我们使用Spring和Hibernate可以帮助我们更加适应这些变化，但仅仅使用Spring和Hibernate技术是不够的，我们还要学会仔细去组织我们的项目。想像一下吧，如果我们使用hibernate2开发的项目现在需要换成hibernate3你需要修改些什么。如果按照我们过去的写法，每个持久化实体一个DAO，那么我们将有诸如StudentDao,TeacherDao,ClassDao等等许多个dao，稍微大一点儿的项目就可能有几十上百个dao。如果因为hibernate的变更使我的这些dao都需要修改，这样的变更带给我们的代价就大了。假如我们通过合理的软件构造，仅仅只修改了DaoSupport的配置和它的实现，这样的变更就仅仅在3、4个文件的变更上，代价是否很小。开发的代价小了，测试的代价是否也就变小？

楼主所指的“我们过去的写法”很可能是说——DAO层中的每一个DAO都分别继承了HibernateDaoSupport，这样导致升级Hibernate依赖或者Spring依赖的时候便不得不提交全新的整个DAO层。

请注意：
每一次升级可以“仅在3、4个文件的变更上”，并不是因为“DAO不直接去使用hibernate或spring对hibernate的支持”造成的，而正是由于楼主所倡导的一个BasicDao基类（及其对应不同版本的Hibernate就采用不同的DaoSupportHibernatexImp）就可以提供全套CRUD无忧的模式。


我们此时就可以讨论一下只用一个持久化操作基类(BasicDao)来完成全套持久化动作的情形：

在DaoSupportHibernateImp或者DaoSupportHibernate3Imp、DaoSupportHibernate4Imp中实现DaoSupport，并且将其以Spring IoC的方式提供给BasicDao。这样一来，所有继承了BasicDao的DAO子类就可以轻松地获得CRUD的能力而又不用同Spring和Hibernate耦合在一起……

那么这样的方式与现在普遍采用的“BasicDao基类继承自HibernateDaoSupport（从而实现基本的CRUD方法），而下面的所有DAO子类又都继承BasicDao”套路有很大的区别吗？

我想，楼主的思路是尽可能使得BasicDao进一步跟以往的依赖解耦。这样在升级的时候除了新的jar包以外，更新的只是Spring的配置文件和一个DaoSupportHibernatexImp的class file，而整个DAO层都可以巍然屹立、不必动一根毫毛。

但是采用了“BasicDao基类继承自HibernateDaoSupport”的套路时，DAO层需要更新的也仅仅是BasicDao一个类而已……

12 楼 freemanxm84 2007-02-01  

楼主介绍下webwork+spring+hibernate的配置嘛。

11 楼 fangang 2007-02-01  

非常高兴能和Allen朋友探讨技术问题 。现在在软件行业比较流行的一句话是“拥抱变化”。我们现在面临着来自客户来自我们的市场对我们提出的变化，关于这个问题的讨论我在《（原创）一个优秀软件开发人员的必修课：GRASP（3）高内聚》中进行了详细描述。我们现在要做的是在变化到来的时候，我们能够付出最小的代价适应变化。我们使用Spring和Hibernate可以帮助我们更加适应这些变化，但仅仅使用Spring和Hibernate技术是不够的，我们还要学会仔细去组织我们的项目。想像一下吧，如果我们使用hibernate2开发的项目现在需要换成hibernate3你需要修改些什么。如果按照我们过去的写法，每个持久化实体一个DAO，那么我们将有诸如StudentDao,TeacherDao,ClassDao等等许多个dao，稍微大一点儿的项目就可能有几十上百个dao。如果因为hibernate的变更使我的这些dao都需要修改，这样的变更带给我们的代价就大了。假如我们通过合理的软件构造，仅仅只修改了DaoSupport的配置和它的实现，这样的变更就仅仅在3、4个文件的变更上，代价是否很小。开发的代价小了，测试的代价是否也就变小？
但是，随着hibernate的越来越傻瓜，我们开始思考我们是不是可以不为每个实体制作dao，而是整个项目就一个dao。这样的做我至今还没有尝试过但至少理论上似乎可行。如果要这样做，即使hibernate变更了也只与那一个dao有关，我们变更的代价就很小了，代码的组织就不必如此复杂了。

10 楼 Allen 2007-01-31  

可能楼主觉得以Spring的IoC方式将实现了DaoSupport接口的类提供给DAO层就是针对现近WEB应用中DAO层过分依赖Spring和Hibernate的问题所提出的“解耦”的步骤……

其实在DAO层的实现类中“耦合”Hibernate和Spring，以IoC的方式将其提供给Service层；对比于楼主提出的在DaoSupport的实现类中“耦合”Hibernate和Spring，以IoC的方式提供给DAO层。这两者之间恐怕并没有什么本质的区别。

况且将来Spring3.0和Hibernate4.0出来的时候，楼主为了升级新建的DaoSupport实现类以及修改了的“spring配置文件中建立引用”了的配置文件难道就不用“打入升级包”了么？

或者又是我误解楼主文章的general idea了？

9 楼 fangang 2007-01-31  

引用

能不能把你的框家配置文件给我发个，我现在想学习一下，这中方法，谢谢，[e-mail]

我在文中写了关于struts,spring,hibernate的相关内容都有，不知sjx003123朋友感兴趣的是哪部分，说具体点儿

8 楼 sjx003123 2007-01-31  

能不能把你的框家配置文件给我发个，我现在想学习一下，这中方法，谢谢，[e-mail]

7 楼 owen123 2007-01-17  

写的不错，继续

6 楼 fangang 2007-01-16  

我的意思是我通过load一个值对象，该值对象有一个属性是set，现在我要将set中的所有值对象都删除，我没有必要去执行一个sql，只需要使用HibernateTemplate.deleteAll(Collection col)就可以了