是多个Action好，还是一个Action好？

我也是这么认为，项目中也是是这么做的，在表单中加一个隐藏字段

你可以一个action对应于一个form，一个动作对应于一个action中的method，这样在层次上和管理上都会比较方便

我感觉还是一个动作对应一个Action，这样权限管理就比较简单了。
比如说某用户只有添加权限没有修改权限。

struts的DispatchAction的话，建议改一下,
使用webwork的url形式xxAction!xxMethodName.do。

hehe ,webwork的这种方式呢，也存在它的问题，就是在用Interceptor的时候比较麻烦，因为Interceptor是对Action的，一个Action多个方法，可能导致Interceptor控制的粒度过粗。尤其是在使用防止重复提交这类功能的时候，问题尤为突出。

只是struts用uri的一个参数来表示执行方法，不是很好。

另外在webwork里
remove
edit
list
这些方法放一个action

save放一个action并且继承上面那个action.

使用struts开发很久了,最初也是认为action多点就灵活,想用几个细粒度的action组装起一个模块。结果是开发维护时在多个类间跳来跳去，头晕。。。
其实都是一个属于模块的处理类，还是放到一个action里方便，然后传参数act来区分动作，这样一来，类少了，重复代码少了，struts-config配置也少了，感觉真的不错。
至于想重用业务代码，其实业务代码要放到业务层作，供action调用就是了。

当然，我不是说一定要一个模块一个action,但这个action。。。还是少点好！

只有采用多个action才符合webwork的模型。如果用一个action, 则需要处处增加一个附加参数，在各处通过switch语句来做不同的处理。这就好像是面向对象之前的编程。因为webwork中隐含假设各个action是不相关的，没有提供对相关的action进行抽象的机制，才是问题的根源所在。可以将业务代码封装在一个业务对象中，action层只是调用业务对象的方法，不做过多处理也不保留状态。

不需要switch，只要定义action的时候指定method就可以。

我比较赞成一个业务模块用一个action，这样可以使你的文件更好管理，毕竟action中只作简单的数据包装，放在一起也不是很大。在控制上，我比较喜欢用swtich语句来判断act的值，然后交给不同的函数进行处理。
swicth(){
  case 0:
  deleteUserById(id);
break;
......
}
deleteUserById(long id);