两种形式，三种写法

最近在看公司的一些项目的时候发现有的项目里面的 mybatis 是基于注解开发的。而我个人的习惯是基于 xml 文件开发。

所以对于基于注解开发的原理不太了解，于是去翻看了一下相关源码，形成此文。

本文主要介绍基于 mybatis 开发的两种形式，三种写法。

其中两种形式是指：

1. 基于 xml 文件。
2. 基于注解开发。

三种写法是指除了 xml 的形式外，注解又有两种不同的写法，它们的实现原理也略有不同，拿 Select 语句举例，就有两种注解 @Select、@SelectProvider 。

演示示例

先上一个演示示例给大家直观的感受一下：

首先，我们有个用户表，包含这些字段和这样一条数据：

image

然后我们搞个接口类，用三种方式去查询用户的年龄，具体如下：

image

xmlQueryAgeByName 方法是使用 xml 的方法去查询用户年龄，对应的 xml 如下：

image

annotationQueryAgeByName 方法是使用 @Select 注解去查询用户的年龄，SQL 就写在注解里面：

image

classQueryAgeByName 方法是使用 @SelectProvider 注解去查询用户的年龄，可以看到注解里面有个 type 字段，对应一个 class 类。一个 method 字段，对应 class 类中的一个方法：

image

其中 UserInfoSql 类如下：

image

然后，再来一个测试用例，把三个方法都测试一下：

image

最后的输出结果如下：

xmlQueryAgeByName whyAge = 18
annotationQueryAgeByName whyAge = 18
classQueryAgeByName whyAge = 18

测试用例就演示完成了，是一个极简的用例。

我就是基于这个案例去分析源码的，在分析之前，其实有点经验的老哥也能看出来了，我们先撇开常规的 xml 文件的形式不谈。

基于 @Select 注解的接口， SQL 就在注解里面，所以我们只需要通过反射取出注解里面的 SQL 进行分析就行了。

基于 @SelectProvider 注解的接口，SQL 虽然在一个类的方法中，但是注解上都告诉你是哪个类的哪个方法了，所以，一定是基于反射去取出方法里面的 SQL 的。

接下来，我们就是去验证一下。

好，准备发车。

image

小心求证

关于 mybatis 我之前写过这篇文章《很开心，在使用mybatis的过程中我踩到一个坑》，其中提到了一个逆向排查法。有兴趣的可以去看一下。

在这篇文章中我们还是来个常规分析吧。本文分析源码为 mybatis 3.4.0 版本。

首先，我先问你一个问题。SpringBoot 是怎么加载 mybatis 的？

image

熟悉 SpringBoot 启动过程的朋友知道，SpringBoot 会去加载mybatis-spring-boot-autoconfigure-x.x.x.jar下 META-INF 中的spring.factories文件：

image

所以，下面的 sqlSessionFactory 方法就是我们的入口处：

image

入口给你找到了，你可以直接在这里加上断点开始 debug 了。

我知道，虽然是刚刚开始，但是可能有些读者觉得已经超纲了。但是没有关系的，继续看下去，我这里只是给你说个入口在哪而已。

image

由于 debug 的过程不是文本重点，这里就不去介绍了。debug 的时候我们会看到这个方法：

org.apache.ibatis.builder.xml.XMLMapperBuilder#parse

这个方法的第 92 行，就是我们的 xml 内容：

image

然后在下面这个方法中对 xml 文件进行疯狂的解析：

org.apache.ibatis.builder.xml.XMLStatementBuilder#parseStatementNode

图片可以点开看大图哦，debug 模式，可以看到一些输出：

image

上面的源码的第 94 行，获 取 SqlSource 很关键，要好好看看，这里调用了这个方法：

org.apache.ibatis.scripting.xmltags.XMLLanguageDriver#createSqlSource(org.apache.ibatis.session.Configuration, org.apache.ibatis.parsing.XNode, java.lang.Class<?>)

image

接着在下面方法的第 52 行，剥离出整个完整的 sql：

org.apache.ibatis.scripting.xmltags.XMLScriptBuilder#parseScriptNode

image

上面就是常规的 xml 形式的 SQL 原始语句（变量、条件表达式都还未进行替换，不可直接执行的 SQL）获取过程，不是本文重点，简单的分析一下就行。

image

接下来继续 debug 的时候会遇到下面这个方法，看包名你就知道，这就是我们关心的注解解析相关的方法了：

org.apache.ibatis.builder.annotation.MapperAnnotationBuilder#parse

在这个方法里面，会去循环处理 mapper 类中的方法：

image

接下来，就会遇到这个方法了：

org.apache.ibatis.builder.annotation.MapperAnnotationBuilder#getSqlSourceFromAnnotations

当循环到 annotationQueryAgeByName 方法的时候，下面方法的一些关键参数如下所示：

image

首先我们看 428 行，解析到了 sqlAnnotationType 为 Select：

image

所以会进入下面的 if 分支，然后运行到 435 行，通过反射获取到了 @Select 注解上的 SQL 语句：

image

继续往下走，通过 436 行，我们可以走到这个方法：

org.apache.ibatis.scripting.xmltags.XMLLanguageDriver#createSqlSource(org.apache.ibatis.session.Configuration, java.lang.String, java.lang.Class<?>)

这个方法就有点意思了，进来判断了 script 即 SQL 是否是以 <script> 开头的，如果是，则走的和之前 xml 一样的解析逻辑：

image

我第一次看到这个地方的时候，一下才恍然大悟过来，我才明白，@Select 的本质还是 xml 文件的形式啊。只是换了个展现形式而已。

我之前的一个问题，或者说是错误的看法也就迎刃而解了。

我之前认为 @Select 的方式是只能支持简单 SQL 的书写，对于一些类似于判空的需求是不支持的。（因为对 mybatis 注解开发确实不熟）

比如在 xml 文件中这样去写：

<when test='startPage !=null and pageSize != null '>
  LIMIT #{startPage},#{pageSize}
</when>

用 @Select 注解时，只是需要用 <script> 标签包裹起来即可：

@Select("<script>"
    + "SELECT "
     + " age "
    + "FROM user_info"
    + "<if test='startPage !=null and pageSize != null '>"
    + "LIMIT #{startPage},#{pageSize}"
    + "</if>"
    + "</script>")
public List<Intger> getUserInfo(@Param("startPage") Integer startPage,
                @Param("pageSize") Integer pageSize);

只是这个写法，呃，怎么说呢，非常不优雅。

不要为了注解而注解，很明显，这种情况直接用 xml 形式更好。

到这里，我们也知道了，基于 @Select 注解的方式开发时, mybatis 会通过反射获取到注解里面的 SQL ，而这些 SQL 需要一些比较复杂功能，比如判断条件是否为空时，可以用 <script> 标签包裹起来。写法和在 xml 里面开发是一样的。

接下来，我们看看 @SelectProvider 方法是什么个样式。

还是在同样的方法中，只是走向了另外一个分支：

image

此时的 sqlProviderAnnotation 里面的东西如下：

image

接着去 new ProviderSqlSource 对象：

image

在这个方法中，获取到了注解上的具体的提供 SQL 原始语句的方法。

注意红框中框起来的 providerMethod 对象，后面获取真正执行的 SQL 语句的时候还会用到。

同时，我们可以看到 ProviderSqlSource 是 SqlSource 的实现类。

所以，不管是 xml 还是注解，最终都需要获取到一个 SqlSource 对象。

image

而在本文的示例代码中， xml 和 @Select 生成的是 RawSqlSource。

@SelectProvider 生成的是 ProviderSqlSource。他们里面放的东西是不一样的。

在 RawSqlSource 里面的 sqlSource 变量（类型 StaticSqlSource）放的已经是从 xml 或者 @Select 注解中获取到的 SQL 原始语句了（但是里面的变量还没替换，因为程序启动过程中根本不知道变量的值具体是什么，如果有一些条件表达式的话同理）。

image

而在ProviderSqlSource 里面，我们前面已经说了，放的是 @SelectProvider 注解上具体的提供 SQL 语句的方法，仅仅是方法，而不是语句。

前面的所有分析都是在我们的方法真正执行之前，接下来，才会 debug 到我们的测试用例，因为只有我们的测试用例里面才有真正的入参， mybatis 才能根据入参，执行最终的 SQL 语句。

image

所以，接下来，我们就是要找到真正生成 SQL 语句的地方，这里就能和之前文章《很开心，在使用mybatis的过程中我踩到一个坑》中的逆向排查法中得出的结论进行呼应了。

image

进入 getBoundSql 我们可以看到第292行，就是通过 sqlSource 的 getBoundSql 方法获取到的 boundSql 对象：

org.apache.ibatis.scripting.xmltags.DynamicSqlSource#getBoundSql

image

这不就又呼应上了吗？又看到 sqlSource 了。

所以，接下来，我们看一下这两个方法就可以了：

org.apache.ibatis.builder.StaticSqlSource#getBoundSqlorg.apache.ibatis.builder.annotation.ProviderSqlSource#getBoundSql

首先看一下 StaticSqlSource 的实现：

image

里面的一些关键参数如下：

image

首先可以 sql 变量，里面是一条待加工的 SQL 语句，我们前面已经分析过了，程序启动的过程中，这里为什么不替换呢？

因为不知道换成啥呀。

那你觉得在这个地方会替换吗？

还是不会的。虽然我们已经告诉 mybatis ， userName 就是 why 了，但如果在这个地方把 why 带到 SQL 里面去，我们倒是可以获得一个完整的正确的 SQL。

但是，如果我们传入的是 “why or 1=1”呢？

这是什么东西我相信你一下就恍然大悟了吧，SQL 注入呀。

另外插一句，如果想看 SQL 注入的情况，就是走到 DynamicSqlSource 的情况，在 xml 中把 # 换成 $ 就行，有兴趣的可以试一试。

我这里只是给你截个图，瞅一眼：

image

好了，我们接着刚才继续说。

继续 debug 会走到这方法中去：

org.apache.ibatis.executor.SimpleExecutor#doQuery

而这个方法的第 62 行，prepareStatement，这个东西不用说了吧，从学 JDBC 的时候就用上它了，老朋友了：

image

最后去执行真正的查询操作，处理返回值。

接着看 ProviderSqlSource 的实现，注意看我圈起来的那部分的分支判断：

image

无非就是判断有几个参数，反射方法调用的时候需要怎么传参而已。最终会调用到这个方法里面来获取 SQL 语句：

image

可以看一下这个时候 providerMethod 和 sql 变量分别是什么：

image

而这里这个 providerMethod 怎么来的知道了吧？我们前面刚刚分析过了。

new ProviderSqlSource 对象的时候，我还专门说了：“注意红框中框起来的 providerMethod 对象，后面获取真正执行的 SQL 语句的时候还会用到。”

就是在这个地方用到的。

你看，又呼应上了。

这个时候，我们获取到了原始的 SQL 语句了，也有参数了，这样的场景和我们刚刚分析的情况就一模一样了，所以后面的逻辑都一样，进行了代码复用：

进入第 98 行，也就是下面这个我们之前分析过的方法：

org.apache.ibatis.builder.SqlSourceBuilder#parse

在这个方法中，返回了一个 StaticSqlSource 对象：

image

再次呼应，流程是一样一样的。

image

另外，再说一下，用 @SelectProvider 注解时的 class 对象里面的方法还可以这样去写，有兴趣的可以去研究一下：

image

好了，我们的论证部分就算是完了，我发现这个东西，用视频真的几分钟就讲清楚了，描述起来还是有点困难的，难道是在逼我当UP主吗？

不知道大家看的是否明白了，如果对 mybatis 了解不多的朋友可能看起来有一点吃力，但是没有关系，你就把这篇文章当做一个导读，然后自己搞个 Demo 跑起来，玩一玩就行。

个人思考

其实在写这篇文章的时候我就产生了一个思考。

mybatis 为什么要去支持注解呢？

当然，我们都知道，基于注解开发是趋势，给我们简化了非常多的东西。

特别是 SpringBoot 的出现，可以说是注解开发的黄金时代。

遥想当年刚刚入行的时候，开发一个 SSM 项目大多数时间都是在进行 xml 文件的配置。

可以说是很羡慕现在入行的小年轻了，没有真正经历（也许自己搭建过，玩了一下）过被 xml 配置支配的恐惧。

在 xml 时代，大家都是粘来粘去的。而现在基于注解开发了，很多东西都简化了，渐渐的自己也能很轻松的搭建一个可以跑起来的小项目了。

所以，基于注解开发大体上一件很优雅，很好，很值得推广的事情。

为什么说大体上呢？

因为我个人偏见的觉得对于 mybatis 框架来说，没有 xml 文件的 mybatis 是没有灵魂的。

当然，如果你全是简单的 SQL 语句就能实现的功能，你可以用注解开发。但是这个情况，我觉得还是在少数的。

同样，我们可以用注解的形式实现所有 xml 文件能实现的功能。但是我觉得不太优雅。

所以，我觉得一个比较折中的方式是简单 SQL 可以用注解开发，如果是一些有诸如条件判断类的需求的 SQL 还是要写在 xml 文件中。

不要为了拥抱注解，而完全摒弃了 xml 的形式。

你记得吗，在 xml 时代转向注解时代的时候，还有一个经常用到的注解。

image

有人说这是过渡时代的产物，而在我看来，这更是求同存异的完美体现。

这个注解，就完全的体现最近这句很火的话：

君子美美与共，和而不同。

当然这些都是我在写这篇文章的过程中产生的一些浅显的个人看法而已。不具备参考意义。

骚代码

另外，再给大家分享一个我认为的 mybatis 的骚代码吧。

代码非常的简单明了，很久以前第一次看 mybatis 源码的时候我就是觉得有点“骚”，给我留下了深刻的影响：

org.apache.ibatis.session.defaults.DefaultSqlSession#selectOne(java.lang.String, java.lang.Object)

selectOne 方法：

image

该方法调用的还是 selectList 方法，但是对返回集合进行了一个判断，如果集合大小为 1，说明就真的是 selectOne ，如果大于 1，则抛出异常。

说真的，如果让我去实现这个功能，我不会一下就想到这个方法，我会去老老实实的写功能，然后对返回值进行判断。写完之后，我可能才会发现。哎，这段代码和 selectList 方法可以复用哦，然后才提取出来，变成这样。

记得很久之前面试，面试官问我对看过的源码中哪段影响深刻的，其中我就说到了这个方法。

总之，我个人觉得很妙。

image

注意坑

然后再说一个之前踩过的坑吧，还导致了一次紧急上线。

还是拿文中的示例说明：

如果我们把返回值从 Integer 变成 int：

image

用这个测试用例还是会正常查询出结果：

image

但是，如果我们查询一个数据库中不存在的人的年龄呢？比如这样：

image

那么就会抛出这样的错误：

image

找对对应源码，我们可以看到：

image

当返回值是 null 的时候，但是方法上的返回值类型又不是包装类型中的一种，也不是 void 类型，则抛出异常。

看一下这个方法，是 native 的：

java.lang.Class#isPrimitive

image

你想想为什么 mybatis 给你进行了这样的一个判断呢？

那就是如果返回为 null ，自动拆箱的时候会抛出空指针的。

即使 mybatis 帮我们挡了一下，我还是完美的踩了一个坑，写出了空指针异常。

代码是这样的，接收的时候我还是用 Integer 去接收了：

image

但是接口调用方我手贱写成了这样：

image

明白了吧，妥妥的，空指针，没得跑了。

image

最后的话

如果大家喜欢我们的文章，欢迎大家转发，点击转发让更多的人看到。也欢迎大家热爱技术和学习的朋友加入的我们的知识星球当中，我们共同成长，进步。