举例说明：

　　*update中的一个例子
　　需要查出数据进行更新,一种方式是用LoadXXXAction查出，用UpdateXXXAction进行更新；
以上做法导致：一个简单的更新模块，struts配置需要两个action。

　　另一种方式是在UpdateXXXAction中进行分支判断，init就用load逻辑,update就update数据；
重用的是较底层的业务load和update，且只要配一个action；而且以后修改模块，用户也不用在类之间跳来跳去了:一个action类，一个page；(结论：一个模块一个action)

　　*query的例子(观点有改变，这种query设计将多个模块的query在一个action，反而使结构不清溪，有时未必一定要追求action配置最少，而是要追求模块本身的清晰,所以以下的做法是不合适的)
查询的界面往往雷同，通常是查询条件+列表，所以一类查询可以放到一个action里面，比如所有对order的查询,用act区分查询类型(审核查询，回单查询...)和查询后到的页面类似的还有如xxxInfoX.do获取单条记录的xml流，可用act区分查询的table(party,vehicle...)
(一组相似的查询一个action)XXXX

　　*更复杂的录入

　　对更复杂的交互，一个模块一个action更能显出优势来，比如以前做过的ContractPayment和现在的配货单，一个模块往往要操作三张关联的表,这时候在一个action中,用act区分动作,再结合session bean，每次都只对session bean的部分进行操作，直到最后完成全部交互后一起提交

　　*保持大模块的独立性

　　一个大的模块中的小模块应该只属于该大的模块，而不是引用其他大模块中的小模块比如订单查询，在运单中也需要，但建议在运单大模块中添加，而不是在订单中添加了再在运单中引用从维护角度讲，大模块间的相互引用会影响可维护性。当然，适当的引用还是可以简化开发的，特别是确定和业务模块无关的小模块（以后不会随业务的改变而有变动），比如在运单大模块中的查看一张订单信息的小模块，仅是查看一条信息而已，可以跨模块引用。