xmlhttp+webwork+spring+hibernate－项目小结

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的一个包装而已。

我反对把事务管理推到Action去做。反过来说，如果你这样做的话，Service层就没有必要了，那么你的可复用的业务组件何在呢？对于某些业务逻辑复杂的应用，例如复杂的工作流，你总不能做出来一些可复用的Action提供给其他Actioni调用吧？

我先简单把这个行政管理的业务简单介绍一下：
横向化分：主要是信息管理、会议管理、车辆管理、办公用品管理等。
纵向化分：主要是流程、表单处理
对流程部分，我们有了独立的工作流引擎。它提供了一个WorkflowService，用来统一查询流程状态，执行工作流动作，驱动流程发展变迁。
刚开始，我们考虑将业务完全独立出来，当然是放在Service层，而工作流则在Action层集成（其实就是一个WorkflowService）。
这时，Service层就是对表单的处理。但在开发中发现Service只是对DAO的简单包装，并没有什么可重用的业务。
    事务的管理，我顷向于在Action层处理。理由：
    1、一个Action的方法是一个完整粒度的操作，一个操作要么成功提交事务，要么失败回滚事务。如果将事务放到Service层，那么一个Action方法中如果调用2个或2个以上的Service方法时，如果一个Service方法失败可能会导致部分事务回滚。
    2、架构的本身。我们的WorkflowService是在Action层集成。在做流程申请（或审批）操作时，通常做二个操作：一个是业务数据的保存（例如表单数据）另一个是流程的申请操作。我们肯定要保持他们的同步。这时，只能在Action层做事务处理。

我也有这种经验，应该将事务处理放到Action里，以保证工作流操作和业务同步。

同意！service不仅仅是对Dao得简单包装，而更多地体现的是对业务的可复重用！action仅仅只是一个控制器，如果action完成了service的工作，service当然也就没有了存在的价值！

我的Action仍然是充当控制器和FormBean的角色，我只是把Service层的事务放到了Action层，Service其它功能依旧。这也就是说，我的业务逻辑，仍然归属于领域对象或Service。

action应该尽量简单，既然需要调用两个 service方法 ，那就在service层增加一个method，来调用 这两个service方法。
这样无论从分层底角度 ，还是减少层间依赖底程度 都是 大有好处。
Service层的设计可以做一个细分，一些基本 CRUD操作可以用一个抽象的abstractionService概括，具体Service设计一般从其所操作的实体对象和具体action推出 ，这样service设计也是围绕action为中心的。

如果考虑使用service,实际上就应该为service增加一个方法。

这个问题和如何实现WorkflowService有关系。
不过，流程和业务数据之间的绑定必须是同步吗？如果足够灵活的话，感觉上不是必须的。

一个Action的方法是一个完整粒度的操作，一个操作要么成功提交事务，要么失败回滚事务。如果将事务放到Service层，那么一个Action方法中如果调用2个或2个以上的Service方法时，如果一个Service方法失败可能会导致部分事务回滚

我倾向于把事务管理放到service中，并且运用外观模式，使其方法作为一个独立的业务过程。

我觉得action里面调用两个及两个以上上的service层的方法本身就有点问题，action负责流程转向，你这里的一个完整料度的操作，应该推到service层的一个独立方法中，因为service层就是干这个的，逻辑封装，不是么？这个service层的方法可以有多个DAO层的方法调用(如果有DAO层的话)，这样，事务不就没问题了么？