前段时间帮朋友处理java后端架构问题，看到了mybatis-plus，其实早几年就知道这个东西，但一直没用没学，这两天许久未见的web服务看了看，聊聊个人感受
如有不适，请见谅
优点
本文没有优点介绍，若要看到优点，自己去官方文档看吧，全是优点，明明白白
缺点
两大缺点足以限制其在大规模服务中使用：入侵Service和Controller、查询代码太复杂SQL被封装拼接导致的可读性差、不利于优化。
就这俩足以泯灭其他光环，懂了就直接跳到小结
1.对数据访问层DAO的上层入侵太强，入侵到service、甚至controller！
mybatis-plus其中，其中重要的plus的东西就是帮你把大多数简单查询给封装了
上一段代码
mapper的XML文件
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="qky.api.dao.UserDao">
</mapper>
DAO层
@Mapper
public interface UserDao extends BaseMapper<UserEntity> {
}
Service层
public interface UserService extends IService<UserEntity> {
}
@Service("userService")
public class UserServiceImpl extends ServiceImpl<UserDao, UserEntity> implements UserService {
}
Controller
UserEntity userEntity = userService.getOne(new QueryWrapper<UserEntity>().eq("mobile", mobile));
-
乍一看，这特么舒服，开发效率嘎嘎的！可是，那个“mobile”知道是啥吗，是数据库表的column！到这里能感觉到问题吗？？
-
问题很明显，数据访问层或者存储层的东西直接入侵到Controller了！！！
-
说实话我第一眼看到在Controller层出现了表的列名，我就感到不适！即使在Service层也不应该出现
-
大家看，从xml到dao接口到service接口和实现类，完全没有一个方法定义（没有删减代码贴过来，直接复制的），那么直接我在Contoller层直接可以做查询，简单的CRUD方法，在那个Iserver里,在那个BaseMapper全部定义好了，关联表查询等只要你按照规则定义好也可以直接在Controller直接自己构造一个QueryWrapper即可完成查询
-
有人会说，这有啥问题，我自己开发我去查下数据库表结构不就可以了。是的你个demo作品，你个小流量网站几个人撑起整个研发团队，是没啥问题，但是一旦跃迁到微服务，MVC分层思想，业务复杂度架构复杂度变高，你说这么开发，它是不是格格不入：看似DAO–》Service–》Conroller 层次明明白白，但这都是虚的，从你实现的情况来看，从你所谓的DAO、Service、Controller其实都归属实际意义上的DAO
-
总而言之，第一个缺点：对DAO以上的层次结构入侵！耦合起来了！
补充：有人说这是MP的错误用法，正常开发不会这么干（另外一些没那么熟MP的人呢？）。没错，那么从另一个思路考虑：一个工具应该提供简单明了通用合适的使用方法，错误的或者说不适当的使用方案就不该提供，只会徒增使用者能力要求（要求有能驾驭得住的正确的姿势的架构师从提供的所有可行的方法中找到合适的组合链路），其实就是徒增使用成本（代码评审、编码原则制定等等）。
2.查询代码拼接逻辑复杂，最终SQL黑盒，不清晰，不利于业务性优化，不利于排查问题
这里说的复杂、不清晰、不利于，都是相对SQL而言，单纯看MP来评价当然会有有人认为也很简单
-
如上代码，这个大家想到了类似的dao框架还有啥？springData、Hibernate。。。。这俩应用广泛吗？NO
-
你想想在代码中用什么eq，like等等一堆方法一个一个字段拼接出来一条语句，一旦字段一多，条件一复杂，可读性直接没了。开发一时爽，维护时，一脸懵逼，想直接重构。扪心自问，你看到别人一坨代码只为了拼接一条sql，你要不要骂两句，你烦不烦
-
有人说了，在xml文件用标签、这些不也是一长串代码吗？你自己好好比较可读性，后端开发如果不是很熟mybatis-plus，会看得很吃力，额外学习成本，而会mybatis-plus的必然会mybatis吧？而且在XML文件中大多数看到的是SQL语句，SQL是最流行的语言了，sql要干啥很快就能分析出来吧，而且代码中QueryWrap拼接出来的查询，仍然是被翻译成SQL语句，我直接写sql语句，简单清晰，他不香吗
-
单表，字段少逻辑简单当然易读，字段多，逻辑复杂，读起来相对于SQL会复杂些，你要花时间硬读，当然可以读的懂，年轻时间多当然可以
-
简单点就是：不利于维护，可读性不强，额外学习成本，查询黑盒子不利于业务性优化和性能逻辑优化。这几个其实就是SpringData和Hibernate等ORM框架虽然开发效率高但是仍然使用很少的一个重大原因。
以上两个（可能说了多个点）点，个人观点，足以让mybatis-plus难以在复杂大规模服务上应用，可以学习思想思路。
mybatis他不香吗？写sql都不愿意写？简单的通用的查询用代码生成不就行了！！！你还一个一个去敲？什么年代了
小结
-
MP单表的便捷能力，mybatis全都可以用代码生成器实现，而且代码生成器可以定制，CRUD列表分页批量操作等等，包括嵌入业务逻辑。那么，MP是不是比较尴尬：MP很多人都是单表用增强的方法，多表写原生xml SQL，可是mybatis单表代码生成器，多表也写SQL，更快更轻量更易维护
-
倒不是要一棒子打死MP，他有他可以使用的场景，但不代表mybatis达不到他的效率或者便捷性。只是出于上述的一些能力考虑，给各位想了解对这俩区别的做一个这个方向上的思路参考
-
MP和原生Mybatis路线是不一样的：MP增强的是上层横向应用能力，接近业务开发，用代码封装（解决）SQL。Mybatis是往极致的对数据库高性能操作，上层应用开发效率上是让给了它的代码生成器来增强。所以严格来说，MP和Mybatis不是一个维度考虑的东西，MP和代码生成器才是一个维度的可比较的东西。代码生成器保持了Mybatis原生的特性（可维护性、可读性、扩展性、性能等等），并且是可高度定制化的。MP的可维护性和可读性在业务复杂度比较高的场景是要低于原生mybatis的
-
有人更喜欢写代码写MP，但MP局限性比较多，所谓功能增强的并没有那么感人，而已
-
其实回到了原始的考虑：代码和SQL，你更喜欢维护哪一个
个人建议不能大规模应用的框架，了解能做啥和设计思路就行了，你的团队重度使用它的话，那。。。。不多说，只适合快速小应用开发，虽然五脏俱全，但是不足以抗风抗雨！
除非。。。。除非你就是想用它，毫无理由，跟爱情一样！！！
抄录远古长者的范言：
- 你倾向于什么，你就更愿意学习什么，就自然会靠近什么，最终最有可能成为什么
- 相比SQL，任何人都不愿意维护一坨长长的代码
- 初学者，相比SQL，更熟悉写代码，所以会更愿意用代码来解决SQL问题
- 代码实现一时爽，维护起来，有几个人就有几行泪
- 自己维护自己的代码，就好像有些人喜欢挖完鼻子后再闻一闻，掏完耳朵后在欣赏欣赏，回味无穷。但是这件事让别人来做：别人来挖来闻、别人来掏来欣赏、别人来维护你的代码，大都有个想法：砍了你！哪个沙雕写的屎山，还连个形状都没有！
- 有些工具它对效率的提升，随着业务的复杂度和团队的复杂度增加，他的开发效率大可能是前期很快，到了某个复杂度，越来越慢。如果你评估未来业务复杂度和团队复杂度只会收敛在前期，那么你可以放心的用它
不接受反驳！个人观点，如有不适，把浏览页叉掉即可！
