接上篇：https://developer.aliyun.com/article/1228261?spm=a2c6h.13148508.setting.27.6e864f0ezvytvj
三、 把持久层代码写在Service中
把持久层代码写在Service中，从功能上来看并没有什么问题，这也是很多人欣然接受的原因。
1. 引起以下主要问题
• 业务层和持久层混杂在一起，不符合SpringMVC服务端三层架构规范；
• 在业务逻辑中组装语句、主键等，增加了业务逻辑的复杂度；
• 在业务逻辑中直接使用第三方中间件，不便于第三方持久化中间件的替换；
• 同一对象的持久层代码分散在各个业务逻辑中，背离了面对对象的编程思想；
• 在写单元测试用例时，无法对持久层接口函数直接测试。
2. 把数据库代码写在Service中
这里以数据库持久化中间件Hibernate的直接查询为例。
现象描述：
建议方案：
关于插件：
阿里的AliGenerator是一款基于MyBatis Generator改造的DAO层代码自动生成工具。利用AliGenerator生成的代码，在执行复杂查询的时候，需要在业务代码中组装查询条件，使业务代码显得特别臃肿。
个人不喜欢用DAO层代码生成插件，更喜欢用原汁原味的MyBatis XML映射，主要原因如下：
• 会在项目中导入一些不符合规范的代码；
• 只需要进行一个简单查询，也需要导入一整套复杂代码；
• 进行复杂查询时，拼装条件的代码复杂且不直观，不如在XML中直接编写SQL语句；
• 变更表格后需要重新生成代码并进行覆盖，可能会不小心删除自定义函数。
当然，既然选择了使用DAO层代码生成插件，在享受便利的同时也应该接受插件的缺点。
3. 把Redis代码写在Service中
现象描述：
建议方案：
把一个Redis对象相关操作接口封装为一个DAO类，符合面对对象的编程思想，也符合SpringMVC服务端三层架构规范，更便于代码的管理和维护。
接下篇：https://developer.aliyun.com/article/1228259?groupCode=java
