关于MyBatis增强的一些看法

和大多数国内码农一样，我在大部分项目中使用MyBatis作为ORM框架（其实日韩也一样），因为它比较符合我们亚洲人的思维方式，简单易用，学习成本低，容易招到人。

PS. 想想当年被Hibernate支配的恐惧吧~~

前两年开始接触MyBatis增强，其中MyBatis Plus（以下简称MP）和通用Mapper（以下简称tkMapper）是简历中出现频率最高的两个字眼。

特别是MP，提供了MBG到慢SQL分析的一条龙服务，甚至还包括了雪花算法这样的ID生成策略，真可谓面面俱到，接私活利器啊！

关于两者的不同，这篇文章有做简单的对比，感兴趣的可以看一下。
补充一点：tkMapper依赖较少，复用了JPA的注解，配置较之MP更加简单，因此更合我意。

使用一段时间后还是发现有些不和谐的地方，具体表现在：

• 首先，不利于代码评审，SQL和业务没有分离，不能一眼看出SQL写在哪里了。
• 其次，不利于代码复用。面对一堆晦涩难懂的对象查询（都沦落到用MyBatis了，英语肯定不咋滴），又让我想起了Hibernate的Criteria和HQL这样的高级语法糖，其实跟用JDBC手写SQL没有本质区别嘛！
• 再次，不利于单元测试，原来DB这块Mock一下，就可以愉快的做Controller和Service层的单元测试，现在复杂度陡增！
• 最后，接口的不稳定性。比如tkMapper的Example/Condition，MP的热加载等等。

针对以上问题，我的建议是：

• 只使用增强的CRUD部分功能，也就是BaseMapper。这些接口会让你有类似JPA的快感。
• 不要使用Wrapper/Example高级查询，Java注释里也不要出现任何SQL语句。
• 谨慎使用扩展，优先考虑各种成熟的MyBatis插件，或者参考其源码自行实现。

简单不等于简陋，更不等于傻瓜化，增强也要有个度，不然就会走上Hibernate的老路，想想人家Spring Data JPA为啥只实现JPA最基本的CRUD部分吧！

BTW，我还建议学习下JPA（主要是Spring Data JPA），如果你十分厌恶XML这种反人类的设计，或许JPA更适合你！
--- END ---