MVC 架构学习笔记

Service 与 DAO 层方法命名规约

CRUD 是指在做计算处理时的增加(Create)、读取查询(Retrieve)、更新(Update)和删除(Delete)几个单词的首字母简写。主要被用在描述软件系统中 DataBase 或者持久层的基本操作功能。对应这里的 crud 方法的命名，每个人有不同的实践。以下是阿里编程规范推荐写法：

• 获取单个对象的方法用 get 做前缀，如 getById
• 获取多个对象的方法用 list 做前缀，如 listByCondition
• 获取统计值的方法用 count 做前缀，如 countByCondition
• 插入的方法用 save（推荐）或 insert 做前缀
• 删除的方法用 remove（推荐）或 delete 做前缀
• 修改的方法用 update 做前缀

Dao 层应当只负责接收最终的 sql 语句，具体到某一张表的增删查改，因为列表的效率从经验上来说大大低于多次查询单表的效率

Service 层也不是就非有不可，对于极小的项目而言，加了 Service 层，反而增加了代码量，而且 Dao 层中已经预见了可能出现的情况，并进行了相应的扩展。那么，此时就不需要了

业务错误是用返回值来处理还是抛异常来处理

业务层给接口层传递错误信息无外乎几种方式

• 封装统一返回类，一般构成是 code+msg，复杂点可以再封装一层 data 用于存储数据，然后上层先判断 code==true 才去获取 data 内容
• 封装业务异常类，在各个判断或边界检查不符合的时候直接抛出自定义的异常类，上层通过捕获异常来获取非成功流程提示信息

1和2效率无疑是较高的，但1方式功能有限，无法提供比较详细的非成功流程信息

2比1提高了很多的扩展性，基本会满足大多数场景，但代码可读性较差，上层需要通过层层判断来获取信息。代码显得不够优雅，我们知道 java 异常效率低下是因为抛出异常会遍历所有涉及堆栈，具体代码在基类 Throwable 的 fillInStackTrace() 方法里。但其实可以通过在自定义异常中重写 fillInStackTrace() 来大幅度提高异常效率。这样业务异常抛出是不会有堆栈信息，上层只能获取到定义的异常 message

具体该使用1还是使用2完全可以看团队要求，保持统一风格即可，调优本来就是一个取舍的过程，没有十全十美的方案，许多细节只能争取做到平衡，然后去关注其他要点，比如一个烂 sql 带来的损耗可能比 1-2 方案之间的损耗要大数百倍

同时，处理业务异常的时候需要考虑监控报警问题，线上就因为没考虑监控会收集 error 日志以及访问接口时返回为500的次数，没有将业务异常与系统异常分离开，导致监控噪音很大，因此，抛出业务异常的时候应当考遵守以下写法：

• 业务异常特殊处理。在 catch Exception 之前，先 catch ServiceException，业务异常打 info 日志，系统异常打监控也好，打 error 日志也好，无所谓了
• 如果不想这么写，那么业务异常直接封装统一返回类返回
• 记得不要将业务异常直接丢给前端，接口会报500，导致前端同学觉得我们的水平很次，接口经常不能用。我们可以写个全局异常处理，因此处理校验异常 MethodArgumentNotValidException、业务异常 ServiceException 等，如果抛出了除了这些以外的异常，我们打个 error 日志，然后给前端返回错误码与问题描述
• 业务码 code 和 httpCode 区分开，我们的 httpCode 应当尽可能保证是200，当然也可以是301、302、用户无权限401、402等，但是尽量不要是500。业务码 code 则可以自己将一些常见的业务问题总结一下给前端了，比如用户没有写入权限、调用 RPC 接口异常、处理逻辑代码超时等等