从架构师角度谈谈mybatis-plus可能存在的问题

存在这么一个情况：对于缺营养的人来说，医生更倾向于建议他选择纯牛奶，而不是有机奶(因其有添加剂)。然而，大部分人却更加倾向于选择有机奶，

因其口感不错，因此，对于选择纯牛奶还是有机奶，这是个博弈问题。

本篇文章，主要从架构师角度谈谈为什么建议选择mybatis(纯牛奶)，而不建议选择mybatis-plus(有机奶)，大家有任何想法，欢迎在评论区交流。

1  关于dao层技术选型

在JAVA领域，可选择的ORM框架还是比较多的，如Spring JDBC,JPA,Hibernate,Mybatis,Mybatis-plus等，其中，mybatis可以算得上是领导者，具有极强的领导作用。

2 深入分析mybatis plus插件原理

2.1 资料

https://mp.baomidou.com/guide/

https://github.com/baomidou/mybatis-plus

2.2 mybatis 源码架构解析

2.3 mybatis-plus 架构与源码

3 mybatis plus 存在的问题

关于mybatis-plus的优点，这里就不论述了，官网说得很详细，详细参考官网：

https://jiansutech.yuque.com/staff-al4og8/drmyey/brma9c

3.1 增加学习成本

mybatis是公认的，被市场验证过的，程序员普遍认同的，java行业统一认同的ORM框架，但mybatis-plus并未经过市场的充分验证，且更谈不上程序员普遍认同

和java行业统一认同，如此，假设A,B,C,D,E,F公司，都用mybatis(因为是公认的，行业默认标准)，而只有A，C公司用mybatis-plus，在这样情况下，A公司外聘

了B,D,E,F公司的技术人员，这些技术人员加入进来，需要学习mybatis-plus插件，增加了学习成本。

3.2 增加升级和维护成本

1.mybatis版本变化，mybatis-plus版本是否会相应变化?

2.对于mybatis-plus每个版本，是否充分经过市场验证和证明？若出现不能用或bug，怎么解决？

3.3 “百花齐放”现象

在Java开发领域，有这么一个默认共识：在考虑稳定性，可扩展性和生态性前提下，架构越简单，越单纯，越单一，越佳。举几个例子：

例子1：架构的干净与统一

你会更喜欢一个只有一种ORM还是有多种ORM的框架，除此之外，考虑一下新人入手框架的学习成本以及代码的维护成本。

例子2：开发人员的犹豫性

假设开发人员接手一个多种ORM组合的框架，那么他在开发需求时，他应该选择哪个ORM框架呢？
例子3：开发人员的排他性

假设一个只熟悉Hibernate的开发人员接手到一个混合ORM框架吗(暂且定为二混合，即hibernate和mybatis)，当他在开发新需求时，会更倾向于选择hibernate(即使他

知道，在大多数场景下，mybatis性能优于hibernate性能)，而不是mybatis，当你问他为什么不用mybatis时，他肯定会反驳几个让你无法回对的问题,如框架不是有hibernate

吗，照着copy不就ok了？我不熟悉mybatis，刚好框架也有hibernate，方便快捷？没人给我说尽量用mybatis呀，框架有说明么？......

例子4: 开发人员的自我证明与炫耀性

你看现在框架里有多种组合，我也搞一种，A说我封装了一个Json类，B说我封装了算法类，C说我封装了字符串类,D说公司有自己通用的类，E说你们这些都不行，你看

现在hutool(对该框架感兴趣，可参官方文档：https://www.hutool.cn/docs/#/)这么齐全，直接用就好。。。，如此，真是“百花齐放”，难以控制。

3.4 DB和架构师视角

根据mybatis-plus源码，随机抽取几个功能接口来分析：

1 T selectById(Serializable id);

1.基本性能视角：假设用户信息表有100个字段，100w条数据(其实，100w数据是远远不够的，一般有一定业务量的，都是千万级别)，每次都SELECT * FROM user_info，结果会怎样？
2.dba或架构师优化视角：某天，系统很卡，问题反馈到DAB或架构师处，他们均不能直观的看到sql是怎么写的，也没有时间去研究源码，也没时间去反编译，那么他们如何去优化？

3.联合主键视角：某天，发现仅仅通过主键id不能解决性能问题，需要建立联合索引，此时，该如何解决？

4.表Join视角：从用户维度，我们能拆分成很多部分，如用户基本信息表(静态)，用户信息表(动态)，用户组表，用户资产表，用户权限表，用户部门表，

这些表如何进行join查询，该如何解决？表的水平垂直拆分，也是相同道理。

5.代码评审视角：代码评审最重要的是确定代码业务逻辑的准确性，其中包括两部分：(1)代码及代码逻辑 (2)SQL语句，而mybatis-plus将CRUD封装在框架内，

无法直接看到SQL，那么在评审SQL时，如何评审，更恐怖是的是，如果DBA参与评估的话，他看不到SQL，在他那里评估就过不了。

3.5 安全视角

以用户信息表为例，假设该表有100个字段，其中手机号，身份证，姓名，年龄，资产为其中字段，现在有个需求：需要开一个接口，统计年龄大于30，

资产100w以上的人id,姓名，手机号，会有什么样的问题？

问题一：将不需要的字段用户身份证，用户资产字段暴露在网络传输中，被第三方抓包工具抓取数据，用户安全信息存在隐患。

问题二：若进行DTO转换，是否存在转换成本，这里会有两个性能IO代价，代价一是从DB库捞取数据成本，成本二是DTO成本。

3.6 不利于架构发展

研究过mybatis-plus源码的同学知道，这个封装版框架是将mapper和service捆绑一起的，然而，在微服务架构，中台架构，尤其是DDD驱动设计中，

service和mapper并不是耦合的(否则会造成domain贫血)，对DDD领域感兴趣的同学，可以去研究领域驱动设计《实现领域驱动设计 （美）弗农著》，提供DDD简要架构图：