xmlhttp webwork spring hibernate－项目总结- -
最近刚帮公司的一个行政管理项目做了一个技术架构：
展现层技术：JSP+XMLHTTP，复用了公司已有gird控件和XForm技术。 Web层框架：灵活的WebWork当然是我的首选 中间层框架：Spring框架，主要使用它的Bean管理功能，完善的Hibernate的基础设施，以及强大的事务管理功能。 持久层框架：成熟的Hibernate 总结：
1、表单数据通过XMLHTTP生成了一个完整的xml文件，传递到后台的Action。我们做了一个xml数据的Interceptor，将xml数据自动设置到Action的属性中（这里的属性通常就是实体）。 在这里，我要顺便说一句：在项目刚开始没有考虑使用XMLHTTP技术，视图只用JSP。后来应美工mm的要求，使用了公司的grid控件，我们的Action没有改动一行代码，加了一个Interceptor轻松搞定。再次让我深切体会了WebWork的灵活。 2、这个架构中没有DTO这一层，我们在Action中直接使用实体作为FormBean，当然，如果一个表单对应多个实体，为了展现的需要我们还是会构造一些DTO的，DTO只在必要的时候使用。 3、事务管理放在Action这一层，做了一个事务管理的Interceptor。它在Action执行之前打开事务，在Action执行之后Result执行之前提交事务。这样，每个Action方法是一个完整的事务单元，又可以避免页面编译出现的异常导致事务回滚。 4、模块化管理主要通过xwork.xml定义文件中的include标签和ApplicationContext.xml文件的import标签来实现。 5、这个项目组的成员都第一次使用WebWork，学习能力强的并且熟悉类似Web框架（例如Struts）的同事，可以快速上手，遇到问题，简单的点一下马上就能明白。但对一个只简单掌握Struts的新手，却需要一个相对较长的学习周期。特别是对Interceptor自动通过表达式语言将数据组装到Action的属性中不能理解，我明明说的很清楚了，他却总是持有怀疑，认为只有手工从request取数据心里才踏实。当然，做过一个模块之后WebWork的原理就慢慢熟悉了，也开始惊叹WebWork的功能强大和灵活。 6、还有一个有待讨论的问题：在这样的架构中，Service层是否必要。因为我们的系统很少有所谓的业务逻辑（流程的操作已在WorkflowService中提供）。记得Potian说过Service层应该尽可能的薄，最主要是提供事务的功能。但在我们这个应用中，事务是在Action层实现，Service层似乎没有起到任何作用，甚至很多只是对DAO的一个包装而已。 |
|
|
