项目小结（hibernate + spring + webwork)

 

目前情况：

       自动工单管理系统，使用自开发的类似struts的架构，数据库访问经过包装，返回string数组。 其架构问题：

Action使用同步锁，导致在同一时间只能进行一次web访问，如同时有其他访问，将不必要的被阻塞。

结构不够清晰，不能够完全按mvc的思想明确的分离各层逻辑。jsp代码过多且结构零乱，没有把通用的代码用taglib等技术抽象，后续开发困难

业务逻辑和数据库紧密相关，而没有从表实现中抽象出来。同时，在每次使用同样的业务逻辑的时候都要反复的进行相关sql编程。故而与数据库有强耦合，相关程序重用性低，可读性差。其翻页机制逻辑横贯架构，使层次高度耦合，而数据库封装也可能存在性能问题。

同时，客户也提出了不少整改意见，而在原版本的修改和升级都会较为困难，而且对长期的维护不利。

项目分析：

       目前的各种业务管理系统还是将以j2ee的b/s架构为主流，所以有必要完成一个通用的，稳固的整体架构作为以后各种应用的坚实基础。

我认为应尽可能使用业内先进的免费框架技术而不是自开发框架。好处是：

这些框架技术凝聚很多业内精英的智慧，而且经过发布和使用，技术体系已经成熟，性能有所保障。

层次清晰，符合先进的技术理念和设计模式。同时也容易找到熟悉相关技术的人才，维护和后续开发方便。

相比之下自开发框架因为技术实力和时间问题，很难达到这些业内领先框架的技术高度。

   分析一般的j2ee应用，应有如下层次：

显示层 负责界面显示，接受用户指令

显示层有较为经典的MVC，即model,view,control，进一步了细化了显示层的工作。此类著名框架有struts，webwork,spring-mvc等。经考察，我认为struts虽然是时间最长最成熟的技术，但易用性和一些架构理念不如webwork，而view层的开发应尽可能简单快速。故选定用webwork.

 

逻辑层 负责进行业务逻辑的实现

目前的开发过程，往往陷入逻辑层和数据访问层不能分离的情况。面向对象的项目开发最后演变成成程序员在程序各处手工写sql操表。这样做的优点是开发迅速有效，问题是结构将日益混乱，每次逻辑的变化将不得不修改分散于各处的sql语句，而后续的程序员也必须了解整个程序和数据库结构才能进行修改。如果是短期小型项目，可以用这种方式。否则的话，我认为应尽可能贯彻面向对象思想，把业务逻辑抽象出来。

而逻辑层的工作就是针对实体对象进行业务逻辑的实现。我们针对所有的业务操作，对外提供service接口，既服务接口。这类似tuxedo和ejb所采用的业务外观模式。而为填补service生存周期管理的空白，我们使用著名的spring框架。优点：

实现Ioc，使各层次的耦合可配置化。

按需要实现单例模式等，进行生存周期管理

事务管理。Spring的宣言事务管理（Declarative transaction management）使得一般场景的代码中将不需要考虑事务问题而集中于业务逻辑

拦截机制将为程序提供很好的扩展空间

 

    3.  数据访问层 负责将类操作映射为数据库操作。进行实体类的持久化。从而将所有的数据访问工作集中起来

           这一层我们将完成实体类持久化(persistence)，有若干选择：

                     1 jdbc实现

                     2 使用ORM工具 如hibernate,ibatis,jdo

经过实写代码，感觉用jdbc实现dao效率非常低，而且容易出错。经过考量选用hibernate。和ibatis相比虽然上手慢且不够灵活，但其架构思想和强大功能都受到业内一致好评，甚至是ejb3也深受hibernate影响 。所以hibernate是很好的选择。

项目设计

              综上，我们使用 webwork+spring+hibernate的架构。

版本：webwork- 2.1.7   spring1.2   hibernate-3.0.3

 

经过一段时间的开发，目前架构基本成形：

      

在src目录下为java源码 dao    负责数据访问对象的定义和实现  其中Dao结尾为接口，Impl结尾为实现。目前一般用hibernate做实现。 domain 实体对象 logic   针对实体对象封装的逻辑  这里service是外观接口，serviceimpl是实现，考虑目前情况简单，并没有进一步分离逻辑，业务逻辑都在impl中完成。 web    界面相关的java类  common是一些常用类，如处理中文问题的filter.  displaytag中放了displaytag相关的类，多为wrapper.  webwork中都是对应的action， 其中 BaseAction是基本的抽象类，基本后续开发应继承此类 CrudAction是为了一般的Crud工作而作的一个抽象类，可以继承用来简化工作。 而CaseDispatcher负责菜单点击后分发到相关Action，同时处理权限和session工作。   其他action按模块进行了组织

左边是webroot的结构     重要的配置文件有： Spring applicationContext.xml applicationContext-db.xml Webwork xwork.xml webwork.properties i18n  labels.properties log4j  log4j.properties displaytag  displaytag.properties dbConnect  jdbc.properties

 

关于一些技术难点和细节：

1．  各框架连接：spring到hibernate使用spring的hibernate支持。Spring到webwork使用autoware的拦截机制自动装配。

2．  列表的问题，采用displaytag。功能强大，使用简洁，可实现排序和数据导出。

3．  数据下载，使用displaytag自带的excel下载

4．  文件上传，使用webwork提供的解决方案，用拦截机制实现。

5．jsp代码组织方面，我们使用taglib和css技术使jsp中页面逻辑减少到最小，一般情况完全可以不使用<% %>的script段 。同时我们使用两个include来包含常用的taglib定义，js引用和html结构，使jsp代码非常简洁。

6．  中文问题 我们使用filter来解决页面gbk到java程序unicode的转换，同时通过正确的设置数据库连接url完成和数据库之间的交互。

7．  I18n国际化。我们要求在jsp代码中不出现中文，所有提示信息都通过资源文件labels.properties来完成。页面中可以使用jstl或webwork标签来调用。

8．  界面验证问题。使用webwork的validate机制用xml定义，或在action中代码判断。