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

看来我是页面驱动了！根据页面展示，来获取要执行的业务方法！

真搞不懂，这个贴怎么会隐藏。。。。

又被隐藏？真是看不懂，看来人们对于不愿意看到的东西就隐藏它，也不管他是不是正确和有价值。

我觉得我发的贴是webwork中一个普遍存在的问题，struts中对此情况专门提供了一个DispatchAction，而webwork中虽然提供method参数的配置来达到此目的，但webwork内部机制决定了这种使用action属性注入的方式会导致额外的大量方法无关的实例属性，不符合单一职责和对象高内聚的原则，也直接导致了action单例无法做到线程安全的特性，webwork官方文档还以现代的JVM创建对象不需要过多成本作为安慰自己的理由。
论坛上唯一讨论过此帖类似内容的是基于struts的框架来提出的，但很明显struts和webwork的实现机制不同，不具备可参考性。所以发表此帖，一方面是寻求更好的解决方案，二是发泄一下自己对webwork部分特性的不满（虽然webwork的确有很多值得称赞的亮点）。
请各位支持，恢复此帖不是目的，解决问题才是关键，谢谢。

看到大家说了这么多。

个人认为：无论那种方法都是可取的，我们只要理清每种方法的优势和劣势，选择什么办法看项目需求和个人意愿了。

就目前所讨论的，有两种办法：
  1，每个aciton对应一个操作。
  2，同一业务对象的操作都封装到一个action中。

小弟不才，自己先站在大家总结的意见中分析一下各自的优劣了：
  1,每个action对应一个操作。
  这种做法每个类的职责单一，而且分工明确，不过缺点就是类的数量会很多，给维护带来不便。

   2,一个action包含多个操作。
   因为struts的dispathAction可以动态调用Aciton中的方法，而WW也可以通过配置action的method属性来定义方法，所以可以将不同的操作封装在不同的方法中来实现。所以不会给action带来额外用来控制调用的字段，以及一堆if else。
   这种做法的好处就是：方便维护，而且看上去也挺顺的，比如：UserAction.login() ,UserAction.addUser(), UserAction.deleteUser等业务方法。不过一个缺点就是会给Action中带来混乱的属性定义，特别是在ww中，action中的属性会更加混乱不堪。不过，如果归类和注释处理的好，还是可以接受的（这句是偶个人滴观点，HOHO）。

   至于权限验证，两种方法都完全可以胜任。不知道我所说的是否完备，恐怕会有遗漏的地方，还请大家指正。当把各个方面的优劣都分析清楚了，我觉得这个帖子的答案其实也就出来了。剩下的就是自己的选择了。

其实还有另外一个重点，我想说的是在webwork中一个action包含多个操作的做法不合适（在struts中反而没有这个问题），因为在webwork中会带来混乱的属性定义，是导致action不能单例的根源等等问题，这是由于webwork内部机制基于属性注入这种推信息的方式决定的，目前我还没想到好的方法处理这个问题。
我想解决的方法要么是对webwork进行改进，要么就换其他的如spring mvc，要不就忍忍吧（webwork还是有其魅力的）。

呵呵，小心一叶障目，不见泰山。任何一个框架肯定都不是那么尽善尽美的。

根据8/2原则，总会有那么20％的东西会让你不爽，还是选择好各种应对的方法才好。

juyin ，你的困扰的确是很普遍的ww的问题。我曾经也有这样的烦恼，你提出的解决办法也还不错。既然你有这个思路，可以尝试自己写一个框架的，当然你的思路还需要具体细化一些。就像我一样。

是啊，赞同这种观点。

不太明白你的意思，是说在web层使用一个通用的action，根据页面传递过来的参数来如service、method来反射调用要执行的业务方法吗？这的确可以省很多代码，但我想问下调用完业务方法后怎么决定定向到那个视图呢？如果也是通过页面参数来决定的，那显然不合适，不符合应由action控制页面流向的原则，如果是通过服务端配置，那只有对ww的配置文件进行扩展。只所以说这些，是因为最近看过类似的设计，但实现的不怎么好。


重新发明轮子也不是我最想看到的结果啊。。。
另外很想听听你说的关于具体细化的思路：）