硬核！阿里P8带你体验更顺滑的MyBatis，付费资源请低调观看

上一篇分享的是《Spring Boot - 自定义 Banner 图案》，这篇给大家分享《更顺滑的MyBatis》。

MyBatis霸榜的底气来源于其广袤的生态以及国内众多大厂的支持。

一 普拉斯们不香了

从iBatis到MyBatis，再到国内团队以MyBatis Plus为典型代表的诸多周边工具，"Batis"系列套餐的发展历程，几乎又是一部XML的兴衰史。最初的iBatis诞生于2002年，彼时XML在Java乃至整个软件技术界都还相当盛行，和同时期的许多项目一样，iBatis硬生生的将一堆堆XML塞进千家万户的项目里。

许多年后，曾经与iBatis并肩过的社区战友们纷纷淡出了历史舞台，少数像Spring这样延续至今的佼佼者，也逐渐摒弃XML，向代码化配置的方式发展。在这方面，iBatis一直是个保守派，即使在MyBatis接过iBatis的衣钵之后，也只是”重磅“推出了支持代码执行SQL的@Select/@Insert/@Update/@Delete注解（以及相应的4种Provider注解），用来抵挡开发者们对XML泛滥的吐槽，这是在2010年中旬，然后就再无动作。直到2016年底，MyBatis的主要贡献者之一Jeff Butler正式创建MyBatis Dynamic SQL项目，MyBatis终于开始全面拥抱无XML的代码化SQL构建。

在从MyBatis到MyBatis Dynamic SQL之间长达6年多的空窗期里，开源社区催生出了许多民间基于MyBatis的无XML代码方案，其中流行得比较广泛的是Tk Mybatis、MyBatis Plus这类内置Mapper和自动生成CRUD的扩展库，一经推出就收获诸多好评。包括MyBatis Plus里实际上并不太完备的"条件构造器"功能，也由于当时同类解决方案的匮乏而颇受追捧。与此同时，在MyBatis社区之外，一直在默默发展的JOOQ是一款历史与MyBatis几乎同样悠久的纯Java动态SQL执行库，它的用户群体不大，却口碑甚好。如今在任意搜索引擎上输入"MyBatis vs JOOQ"，依然能得到几乎是一边倒选择JOOQ的结果，大家给出的理由也非常一致：简洁、灵活、无需XML，很"Java"。而在MyBatis阵营里，若是拿出MyBatis Plus的"条件构造器"与之正面对阵，只消三个回合，就会被屁滚尿流地打出擂台。只可惜JOOQ的家底没有MyBatis那样殷实，早早走上了商业数据库支持卖License收费的道路，才让MyBatis免于在舆论上迎来自己的中年危机。

Fluent MyBatis诞生于2019年底，即使与MyBatis Dynamic SQL相比都是晚辈，然而尚处成长期的它就已透出了青出于蓝而胜于蓝的味道。

在实现方式上，MyBatis Plus覆写并替换了部分MyBatis内部类型的方法，整体机制较重，却也因此能将一些功能细节隐藏到用户无需关注的内部逻辑里；与之相反，MyBatis Dynamic SQL的实现机制非常轻量，不仅完全基于MyBatis原生的Provider系列注解开发，而且没有什么隐藏逻辑，对用户的每张表自动生成相应的Entity、DynamicSqlSupport和Mapper三个类，全部放入用户的源码目录里，因此暴露的细节比较多，代码侵入性略高。Fluent MyBatis取二者之所长，整体机制与MyBatis Dynamic SQL更接近，同样基于原生的Provider注解，对用户的每个表生成Entity类和默认空白的Dao类，不同之处在于它还会通过JVM编译期代码增强功能自动生成许多开发者不可更改的标准辅助类，这些代码无需放入用户的源码目录但能够在编码时直接使用，即提供丰富的功能，又保证了用户代码的整洁。

在使用方式上，Fluent MyBatis同样借鉴了前辈们的最优实践，没有花里胡哨的注解和配置，直接复用MyBatis连接，所有功能开箱即用。同时由于Fluent MyBatis将所有表字段、条件、操作都以方法调用形式提供，因此获得了比其他同类项目都更好的IDE语法辅助。举一个不太复杂的例子：

// 使用Fluent MyBatis构造查询语句
mapper.listMaps(new StudentSco