本文为我个人开发中的总结, 仅供参考, 欢迎评论交流
分层+分层后的方法的命名
dao层一般不会有太多的区别, 就是直接操作数据库的, 基本不涉及业务, 仅做操作数据库相关的校验和操作数据库.
但service和controller层使用起来就因人而异了. 基本的规范是所有的业务逻辑在service层, controller层更多的是做入参的校验和路由的功能. 但实际使用过程中, 很多的业务层逻辑会被写在controller层,
==================命名=====================
===controller层===
.restful 风格的api, 要求通过http的动作来标识方法目的, 如:post表示新增, get表示查询, put表示更新, delete表示删除, 所以在api路径中就不要出现add/create/query/update等动词.
.现在的接口基本都是restful风格开发, 但因各种web服务器对http请求方式支持的问题, 造成我们基本都仅适用get和post请求. 所以为了方便的区分统一资源的不同操作, 我们还是会在api路径上添加上动词来表明目的
***除了通过id查询外, 其他的建议都是用实体或者map作为入参, 方便后续增加过滤条件
查询单个: detail(通过id查)/detailByCondition(通过多个组合条件查询, 入参为实体)
分页查询: pageXxx
查询所有结果集:listXxx
删除: removeXxx
添加: add(添加一个实体)/addZzzXxx(添加多个实体, 前端一个表单提交了多个实体信息)
修改: modifyXxx
统计: statisticsXxx
统计数量: totalXxx
===service层===
本文将一个controller对应一个service, 所以service可以和controller层方法名保持一致
service层可以分为两个层类, 一个层类作为controller的全权代理, 处理所有的业务逻辑, 包名可以命名为serviceController, 在一个service方法中,便于整个业务逻辑事务的控制.
另一个层类作为dao层的封装、组合(修改审核状态的时候可能会同时天津市审核记录, 当然也可以通过定时任务完成记录增加), 对dao层做处理, 如果将controller的业务逻辑和dao层的操作放在相同的类里面, 很容易因为发生自调用没有做处理, 而造成事务等aop功能失效的情况(参考:https://blog.csdn.net/changerzhuo_319/article/details/97095755).
===dao层===
以数据库的关键字作为开头描述方法的作用,如: selectXxx, UpdateXxx, deleteXxx, instertXxx, 对于update,insert, select可以考虑入参为对象, 是否添加某个字段的条件以该字段是否为null为标准, 参考mybatis的UpdateBySelective方法
==================职能划分===================
controller: 入参校验, 出参组装, 权限控制等
service: 逻辑处理; 事务控制, 数据操作, 结果集获取
dao: 数据操作
==================其他===================
. 考虑到model中的一些字段可能会有默认值, 但是修改或者插入时我们又采用的是model作为参数, 所以可以做一个工具类, 通过反射等方式,操作生成一个没有默认值得model, 然后再将其要操作的属性值,复制给model
. controller层的入参形式可以是model, Dto, map等, 看项目中的取舍.
model: 该模式对单一实体的操作最为方便, 涵盖绝大部分情况的入参, 但会暴露很多没有用的参数给到前端, 造成接口入参看着比较混乱.
dto:最为精简, 方便。 每个controller方法都声明一个对应的dto, 完全精确控制入参, 又是java类, 方便操作使用。 但会操作声明N多个dto的现象, 项目会变得臃肿。
map:最为精简, 但使用起来不方便。 可以完全精确控制入参, 虽然不用在声明N多个dto, 但因其需要输入key,操作起来不方便。
出参也可以参考上面的描述。 追求功能的完善就使用map, 可以做一些妥协的就使用dto, 没有过多约束的就可以使用model。
对于出参,最好统一项目的输出格式(参考:https://blog.csdn.net/changerzhuo_319/article/details/55669119)