有没有人在struts2的action这一层做事务控制？

如果有很多这样的需求，是否每次都需要编写一个单独的组件？
action作为controller，本来就应该起到流程控制、转发等作用，这是它本职的工作，不应该交由业务层去
处理

此流程非彼流程，不要仅从字面理解
mvc中controller要控制的是页面转发的流程

事务处理和action无关
如果真的想这么弄  别用struts了
直接用jsp servlet 挂个spring不就完事了么

这句话不太理解,我是这样认为的,为避免web层和business层的藕合,
action里面仅仅是获得request然后交由业务层去处理,然后
处理返回后forward到某一页面.

你这样的需求可以在web tier 和 business tier加一层
business delegation层.由它去调用真正的业务方法.
需要对业务方法进行事务控制也在这个delegation里做控制
比如:
       class BusinessDelegation{
             operation1(){
                 service1();
                 service2();
                 ......
             }
       }
     对operation1加事务控制就可以了.

不可否认你说的这样很理想，但是也正是因为理想，跟实际是有差距的。之前的项目，虽然也是对MVC或者说
DAO-BO-VIEW三层做了要求，实际项目做下来，因为时间等客观因素，导致最后有很多业务逻辑直接写在
Action里面。现在我们对项目的技术框架重新构建，虽然这次严格要求业务逻辑要从Action里面抽取出来
放在BO里面，但是如果按你说的这样再抽取一层，必然会增加大量的工作量，使得这次技术框架的调整风险
更大。

[quote]action当然不应该封装业务逻辑，但是action是controller，比如[b]在一个action里面可能会由几个Business Service的方法组成一个流程[/b]如果仅对service的方法实现事务控制，那如果流程中某一个service 的方法出现了问题，流程中之前调用的其他service怎么回滚呢。 [/quote] 设计不好,应该避免这种情况, 最好事务控制在service的方法上

可以考虑open session in view  用struts2的intercepter

web层主要的作用是获取request中的数据,组织好交给service来处理，再然后处理service返回来的结果
也就是说web层起组织数据和处理结果的作用
而不应该用几个Business Service组成什么流程，这个流程应该在web层之下来完成

另外：dao在不是特复杂的项目里面跟本没必要保留，直接service会大大提供生产效率。

不需要单独一层啊，有时候提供一个粗粒度的方法就够了。我建议业务层的每个子模块里只有极少量的Service类，每个负责一大组相关的业务，接口都足够的粗。Service类实在太大了之后，可以重构出一些内部类，但出口仍然是Service的粗粒度接口。

Action无论如何，不可以调度同一事务内的多个业务方法这条约定我觉得是还是必要的，否则就很容易像你说的把业务逻辑直接写在Action里。而且，遵循这条约定其实不难。

嗯，其实这也是我以前一直的做法，只是现在team人比较多，不太容易说服所有的人，或者说保证所有的人
都这样做有一定的风险。
现在已经用拦截器的思路实现了，有了这一层的保障，再尝试用规范约束吧。