目前情况：
自动工单管理系统，使用自开发的类似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中代码判断。