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 接口异常、处理逻辑代码超时等等
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。