关于webwork在同一个action中实现CRUD多个操作方法的问题

为了减少action的数量，我一般把对单表的CRUD操作放在同一个action中实现了，但问题来了：
这样action的属性（实例变量）就会很多很杂乱，比如一个产品表的操作至少需要注入以下参数
List productList;//查询方法需要
Product product;//增加、修改方法需要
还有分页参数等等
搞的不好还有String productId之类的
这样导致action的逻辑看起来很混乱。

不知大家是如何处理的呢？
单一职责固然合理，但如果因此而引入大量的action类导致其他的如管理上的问题又是否值得呢？况且单表的CRUD操作之间也可能是有关联的，如删除操作后可能需要调用查询操作来返回一个新的产品列表。
我甚至觉得这是webwork设计上的一个问题，使用无侵入的getter/setter方式和视图间传递（交换）数据本身没有问题，但在action中使用属性（实例变量）也会带来很多的问题，不够清晰，而且搞的最后action也只有每次产生新的对象来保证线程安全问题，还有action的返回值使用String也不够OO,连struts都用了一个ActionForward来封装。
顺便说说我比较希望的方式：

public class ***Action implements Action
{
   private ProductManager productManager;//通过spring注入或其他方式初始化    
    public ResponseOjbect update(RequestObject reqOjb)
   {
       Product product =(Product)reqOjb.getRequestArg("product");
       productManager.update(product);
       ResponseOjbect respOjb=new ResponseOjbect();//类似Spring的ModelAndView
       respOjb.addOjbect("product",product);
       respOjb.setView("success");
       return respObj;
   }
   .....
}

和事件机制类似，操作的输入输出数据都在方法体内，保证了单action的线程安全。代码比webwork长了点，有点像Spring的MVC了，但又没有和servlet产生依赖。

我会写四个Action，分别处理的，呵呵。

你自己都觉得这样逻辑上有问题，
每个类职责上要单一，

有个不明解的地方:
楼主为何要注入List productList,Product product这些变量?并将它们置为实例级?

方法的本地变量不就可以了吗?我是以struts来理解的.

一定要用多个action啊，不然到最后你的这一个action会相当凌乱，然后你会非常痛苦

Not bad。至少敢往大众流行的反方向想。

不过，具体如何做，这个依赖于你的项目情况和人的情况。

不管怎么做，凌乱都是不好的。

可以给你参考的是，我的做法就是所有CRUD都是一个ACTION，并不显得多凌乱，类是大了点。但我的编程方式跟你的不同，我是元数据编程，某些角度可以类比于ROR。但这个平台的工作量是比较大的，可能不适合你。

就像国外的初级教育一样，要给敢于反方向想的人予以鼓励。

减少action的数量还是很有必要的，而且人们也确实是这么做的，Struts的DispatchAction不就是为解决这个问题出现的吗,可以每个方法处理一个请求,有效避免了action数量的爆炸式增长。
而且处理请求的参数都是局部变量,不需要实例变量呀?

表单处理最繁琐之处是validator、国际化、表单数据绑定和回填，这些基本的常见需求单个实现起来都很简单，但是要给出一个集成所有这些东西的简洁的方案还是要费一番功夫的，这方面SpringMVC的SimpleFormController解决得最优雅，也是我在众多MVC框架中偏爱spring的重要原因

我们的作法也是一个业务模块一个XXManagerAction 包含该模块的所有业务操作，当然对与一个类包含CURD操作要有一定的约束与规范，才能不至于凌乱

同楼主，我以前也是饱受了action数量太多的痛苦而用这种把同一组业务逻辑都组织到一个action当中，当然也会带来可能会造成对象变量的凌乱，不过只要归好类别，注释写清楚，不会有什么问题的。

有点不同的是，我用的是webwork，免去了在actionform。

其实多个action或者一个action多个method还是看个人喜好了。并不一定谁优谁劣。

单一职责固然合理，但如果因此而引入大量的action类导致其他的如管理上的问题又是否值得呢？况且单表的CRUD操作之间也可能是有关联的，如删除操作后可能需要调用查询操作来返回一个新的产品列表。
我甚至觉得这是webwork设计上的一个问题，使用无侵入的getter/setter方式和视图间传递（交换）数据本身没有问题，但在action中使用属性（实例变量）也会带来很多的问题，不够清晰，而且搞的最后action也只有每次产生新的对象来保证线程安全问题，还有action的返回值使用String也不够OO,连struts都用了一个ActionForward来封装。

顺便说说我比较希望的方式：

public class ***Action implements Action
{
   private ProductManager productManager;    
    public ResponseOjbect update(RequestObject reqOjb)
   {
       Product product =(Product)reqOjb.getRequestArg("product");
       productManager.update(product);
       ResponseOjbect respOjb=new ResponseOjbect();
       respOjb.addOjbect("product",product);
       respOjb.setView("success");
       return respObj;
   }
   .....
}

和事件机制类似，代码比webwork长了点，有点像Spring的MVC了，但又没有和servlet产生依赖。