如何恰当使用webwork种的Action?

大家是怎么使用webWork种的action呢？是象strust那样只是做一个流程控制 还是不把她做成 业务对象？ 如果只做流程控制的话，和 struts比起来也没什么优势，如果把她建模为 业务对象的话，岂非把业务层的东西放进了web 层？刚研究webwork,希望大家讨论

“流程控制”和“业务对象”并不是非黑即白的两个东西，只不过是业务逻辑的多少程度不同而已。如果web层的环境不好，不方便测试，或者考虑需要支持多种客户端，就在web层少放点业务逻辑；如果web层环境好，方便测试，又不需要支持多种客户端，就在web层多放点业务逻辑。这是一个连续轴上的权衡，没有一个离散的、非此即彼的答案。

在项目中，经常会出现增，删，改，查的情况（比如说维护员工信息），在struts中我的做法是使用DispatcherAction,觉得有点别扭，不知到大家有没什么好的方法？spring mvc 也有类似的功能，好像多控制器，webwork中怎么弄？难到要为  CRUD 写4个Action? 如果把Action视为 业务对象，理论 上 CRUD 四个控制应该在一个Action中才合理，大家的看法呢？
如果用sb做facade的话，业务基本上被限制在facade后了，这时候web层与业务层的通信一般用dto,直接把webwork中action当dto?不然存在类似Struts中的情况，dto到到action的属性复制?

说白了就是“user!register.action”和“registerUser.action”这两个URL你看哪个顺眼的问题，你喜欢怎么就怎么，这种事情哪有定规的。

如果太约束action的数量，把很多action集中在一个action里会有问题。
首先是设计上的问题，看上去维护的action类少了，实际上由于这些action所需的参数等环境并不完全一致，产生了坏味道。
其次对action的验证也很不方便。
然后那种加感叹号的表示方法也不见得理想。
如果却有代码复用的地方，可以考虑在action中加一些继承的关系，仿佛java open source programming中说的。

如果一个Action中只放1－2个方法，Action的继承确实是最好的选择。如果
action放好几个方法也不会有太大问题，在WebWork中，可以为每个Action方法做一个Action配置，验证也不是问题。（但不要过分太多哦）