web应用应怎样开发才结构最清晰

Web应用应怎样开发才结构最清晰

在分层开发web应用时,
web不要过分强调代码的重用性,重用的前提是不影响模块结构的清晰
否则action配置复杂,模块之间的相互调用太多，容易引起混乱
以上的观点在web层肯定适用,也就是client层
当然,往较底层的代码,在业务层，还是要偏重讲究复用性的，dao层更是

举例说明：

*update中的一个例子
需要查出数据进行更新,
一种方式是用LoadXXXAction查出，用UpdateXXXAction进行更新；
以上做法导致：一个简单的更新模块，Struts配置需要两个action。
另一种方式是在UpdateXXXAction中进行分支判断，init就用load逻辑,update就update数据；
重用的是较底层的业务load和update，且只要配一个action；
而且以后修改模块，用户也不用在类之间跳来跳去了:一个action类，一个page；
(结论：一个模块一个action)

*query的例子
查询的界面往往雷同，通常是查询条件 列表，所以一类查询可以放到一个action里面，比如所有对order的查询,用act区分查询类型(审核查询，回单查询...)和查询后到的页面
类似的还有如xxxInfoX.do获取单条记录的XML流，可用act区分查询的table(party,vehicle...)
(一组相似的查询一个action)

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

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

上一篇： 通过实例了解接口的含义
下一篇： Junit FAQ（001-016）

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有