公司有一些刚毕业的在用，让我很无奈。
结论：除了BaseMapper有支持 insert, updateById可以自己从Entity类自动生成SQL外，其他功能一无是处。
1）IService封装
你一个封装数据库访问的，封装的DAO这层，为什么污染Service层的事情？是不是闲的？
2）不做MySQL等中关键字的包装
你写了那么多乱七八糟的功能，为什么这个“点”就是不做？是没时间还是没能力？毕竟这么多年了呀。
3）PageHelper等杂七八糟的点
现代数据库都已经支持了 分页 的功能，这种功能点存在非常鸡肋，也会教坏实习生小朋友。
建议：做好BaseMapper就够了，其他的没必要存在。
1）mybatisplus就是扩展了一些API，比如批量操作等等。
2）不做MySQL等中关键字的包装，这正是它所谓自己是半自动的设计理念驱动的，如果像jooq或者hibernate那样，对关键字封装，那不就成全自动ORM了吗？
3）PageHelper的分页，和数据库的分页，这是两个东西吧？这个点我没明白。
mybatis 是不太行，但你更多是不会用。
上 JPA 吧，这个香！
JPA隐藏了SQL，非常不利于SQL的审查。
最重要的是用数据库不写SQL，这有点违反逻辑，把开发者当成了不继续学习的实习生。
1）最主要的是他做了“不应该”做的。MybatisPlus开发者为了一开始“堆”功能点，做了很多鸡肋的事情，遗留到现在变成了负资产。
2）它可以不做关键词的包装，但是@TableId @TableField来让一个作为ID的包裹‘关键词’的能力它都不做。是没开发实力的体现，这个开发实力还能指望着什么？
3）PageHelper是个例子，那些边加料的鸡肋功能它居然跟宣传成亮点。
这是个思维定势，你写 Java 不会去操心 open/read/write，不操心内存分配，不操心 socket API，为啥用 DB 就要操心 SQL 呢，你写 SQL 会用存储过程吗？
JPA 自动生成的 SQL 都是些简单枯燥 SQL， 复杂的 SQL 逻辑依然可以写 SQL。
除了 MyBatis 和 JPA 外，JDBI 和 Ebean 可以看看。
会写sql的应该都不会想用sql包装吧, 我原来自已写了一个简单的sql包装, 结果我自己总是不记得用, 用到的时候总是想回退到直接写sql。
还是个思维定势，习惯 C 的人写 Java 就忍不住思考内存分配是否高效，而习惯 Java 的人写 C 就会觉得不胜其烦。 汇编 vs 高级语言， SQL vs ORM 都是如此。
这不是非此即彼，现实就是大家都在混用：用合适的工具就好，不要拿一把锤子到处敲，稳是稳，累啊！
c++出身的，感觉也是很不习惯，还不如直接拼sql方便，以前用python 读数据库表结构，然后生成pb文件，再搞个单独的类，利用pb的反射，动态生成sql，达到类似功能，其实就俩文件就搞定了，mybatis主要也是为了通用吧，多后端数据库
但是各种 ORM 不是就是让框架帮你做一套更简单更可靠的数据存储/处理接口吗，非要写 SQL 是为什么呢
我的理解：
最重要的是：ORM的简单和可靠只是理论上的，实际取决于使用的人。我亲见一个兄弟说：MybatisPlus能够极大的简化逻辑，看多简单；但是几次需求变动后，他的那些代码就已经和‘刚拉的’一样了。
国内用 MyBatis 多，是因为 MyBatis 的封装很薄，性能很好，也便于理解代码、修改代码，但想理解 Hibernate，那就困难太多了。国外用 Hibernate 多，是因为他们很少像国内把糙快猛、高性能、高并发挂在嘴边，即使并不需要高性能，即使写出来最终性能依然一坨 shit。
但 MyBatis 真不是个很好的库，丑的一逼。
反驳几点
SQL已经是最小、最简单的可学习语言
SQL 相当复杂，大部分 ORM 无法 100% 覆盖 SQL 的用法，所以 ORM 要比 SQL 简单。
SELECT的优化核心是索引，ORM将这些细节隐藏了
ORM 并没有将索引隐藏，写查询的时候依旧需要注意要使用到索引。如果一个 ORM 框架写出来的查询你都无法判断是否用到了索引，那这个 ORM 多少有点问题。
很多ORM提供的复杂接口，不利于SQL的代码审查
同上，如果一个 ORM 框架写出来的查询你都无法判断是否有问题，无法审查，那这个 ORM 多少有点问题，或者是你压根就没搞明白这个 ORM。
ORM 代替的是简单的 SQL，并不能搞定复杂的查询。 ORM 和索引是正交的，ORM 并不解决索引建立；
那是你用的 ORM 不太行。稍微合格点的 ORM 足够应对大部分复杂查询，而且可以帮你管理表结构的创建修改，当然也包括索引。
我的理解。
ORM 是把非结构化的 SQL String 转换为编程语言能处理的结构化数据。
最直接的好处，就是让你可以不再是只能做字符串拼接，而是可以用所有的工具和设计思路来组织查询。
如果一个 ORM 工具仅仅是字面上做把查询映射到 Object，然后还需要手写 SQL，那这个工具就是个垃圾。
比如我随便复制的一段 lisp 代码
(select (:id :name :sex)
(from (:as :person :p))
(where (:and (:>= :age 18)
(:< :age 65)))
(order-by (:desc :age)))
这段代码你可以把它作为普通的 list 处理，如果你想增加一个 where 查询，就可以 append 一个 (where (:xxx)) 进去，非常的直观。也自然可以做任何应用于 list 的骚操作。
如果是 raw SQL 字符串的话，做相同的事情就比较麻烦，而且也容易出错。
感谢。
如果以‘熟练’作为前提，那么任何ORM都是美好的。
我对MybatisPlus的批评选择的视角是：审查实习生、陌生使用者对这它的使用。 情况是：对它的使用让问题复杂化、质量垃圾化。
之前一个非实习生的人做了这样的封装：从BaseMapper继承一个Mapper，从IService实现一个BaseService，而这个Server直接引入了Mapper。也就是它让 DAO上升到了Service这层，跨Service的操作必须要新建一个层级。
也就是MybatisPlus的误导性很大，造成那个封装产生了误解。
重点：那个封装的人，口中各种对MybatisPlus的推崇，不能说不熟悉和不会用。
这玩意不在 scala 里能用吗
我记得 quill 也只能对简单 sql 编译期生成