第一点:应用要做分层,比如你的dao层只做数据库的CURD,对应的method方法可以为insert、updateById、 deleteById、queryListByOption等,然后上一层为manager层,这一层做原子的业务,比如createTask、 finishTask等,再上层可以做复杂业务,比如service层,可以调用多个manager层的接口完成复杂业务,如商家同意退款,第一步要变更 状态为已退款,第二步要转移资金,再上层就可以为view提供数据,他就只能调用service的接口获取数据并组装给view;
第二点:我理解你说的业务逻辑过多,这些业务逻辑可以拆分成不同的功能点,比如step1做什么,step2做什么等等,这样就可以将业务细化,每一步的业务再编写代码,这样代码清晰,如果还是很复杂的,建议就做拆解,满足ocp的代码后面维护才容易;
总之,其实就一点,要让业务的变更尽量少的修改代码那就行了,不要因为给房子加一个螺丝钉,就要把房子全部整修一遍。
上面是赋值源友 阳光test 的回答,
1. dao层推荐还是用仅操作数据库,
2. service则做业务判断处理,这里如果有依赖多个dao , 你可以新建集中在一个manageServer里面 , 而不是在一对一的service里, 新建类并不费事,前提你的业务逻辑比较复杂,不负杂还是单类好,毕竟类多了还是要维护的;
3.action做分发;数据非空判断,或者权限处理;
本文介绍了软件开发中分层架构的设计思路,包括DAO层、Manager层和服务层的职责划分,以及如何通过合理分层来应对复杂的业务逻辑,实现易于维护的代码结构。
1518

被折叠的 条评论
为什么被折叠?



