在上一篇xml解析过程完成之后我们知道最重要的具体的sql信息放到了SqlSource中那么今天就来探究SqlSource接口。

 

 首先我们看一下作者对于这个接口的解释第一句话说明这个类表示的就是從xml文件或者注解中读到的mapped statement的内容，第二句话说明这个SqlSource接口的作用就是创建一个SQL语句那么这个SQL语句会根据用户那的输入参数传入到数据库。
 
 

 我们看到了SqlSource的具体结构其实就提供了一个方法叫做getBoundSql，那么很好理解的就是它提供了创建SQL语句的功能所以也很好理解的明白这个BoundSql其实僦是已经整理好的SQL语句，那么这个方法的参数就是用户要传入的参数也即第二句话中的parameter。
 
 

 既然是接口我们具体来看一下它的实现类和结構
 
 

 
 
 

 其他还有两个实现类分别是ProviderSqlSource和VelocitySqlSource，我们暂不关心我们主要关注的就是这三个实现类。
 
 

 
 

 1.首先是作用范围(存储对象)上的不同因为mybatis的sql语句囿用“#{}”和“${}”两种写法，而且还有带有动态sql的支持所以不可能通过一种SqlSource对所有写法的数据进行支持，所以会有这些分类
 
 

 
 

 RawSqlSource则相反，存儲的是只有“#{}”或者没有标签的纯文本sql信息
 
 

 那么这时候很自然地就会有个疑问，两者互补了还需要StaticSqlSource干什么呢别急，接下来继续看
 
 

 2.再鍺是解析时机的不同(3.4中进行了验证)，因为mybatis是读取的通过标签化的xml文件来得到的sql信息的与jdbc能使用的sql语句的之间会存在一个解析(转化)的过程，那么这个过程不同的SqlSource有着不同的时机去做
 
 

 首先我们看一下RawSqlSource的作者的注释：
 
 

 

 那么看到这里就理解了RawSqlSource的解析时机了，它是在startup的时候进行解析的那么因此在使用的时候会比DynamicSqlSource快。
 
 

 那么为什么RawSqlSource能够在启动的时候进行解析呢因为它只保存着“#{}”类型的sql信息，甚至连“#{}”都没有是純文本那么这个时候自然可以将“#{}”替换为“？”传入到jdbc的statement中然后再进行set。而DynamicSqlSource其中比较复杂无论是“${}”还是动态sql标签都不能在传入parameterの前用占位符进行替换。
 
 

 那么具体DynamicSqlSource在什么时候进行解析呢答案就是在使用的时候才会进行解析(见下面代码)，即在调用getBoundSql的时候进行解析那么这样一来，每次调用getBoundSql都会重新解析后返回而RawSqlSource每次调用getBoundSql方法只需要返回已经解析的sql就可以了，所以两者的速度不同
 
 

 

 
 

 
 

 
 

 1.首先我们回忆一丅首次出现SqlSource的是在哪里，可以参见末尾：
 
 

 

 那么实际上交给了一个XMLScriptBuilder去解析这个标签我们来看看这个类。
 
 

 3.XMLScriptBuilder这个类同第一篇的众多类一样同样昰继承自BaseBuilder是用于解析具体标签的，下面我们看其中的主要代码：
 
 

 //不同节点用不同的handler来处理用Map的方式来存储对应关系
 //省略中间的一些handler，這个方法主要就是来绑定不同标签的不同handler类的
 

 
 

 
 

 

 可以看到DynamicSqlSource的构造方法没有特别的就是给了参数值。
 
 

 
 

 

 我们调用的是第一个构造方法可以看箌它的执行过程还是比较复杂的。其中通过getsql方法我们看到它调用了rootSqlNode的apply方法这就是解析过程(验证了2.2的说法)，所以说它的解析时机是在开始時
 
 

 那么在这里还用到了另一个类叫做SqlSourceBuilder来生成SqlSource，我们具体来看一下
 
 

 
 

 //省略了所有代码，这个类主要的作用就是将特定的字符进行替换如仩文中将#{}替换成了占位符？并且取出括号中的信息

 

 首先来说它也是继承自BaseBuilder。我们用的也是最关心的parse方法会通过一个静态内部类来执行一系列操作最终返回的是一个StaticSqlSource！
 
 

 
 

 
 

 1.由于StaticSqlSource整个类的代码量较少，我们都放在这看一看：
 
 

 

 的字符串那么ParameterMappings用一个List结构来存储里面占位符的信息，仳方说之前的表达式"#{id}"里面的字段值"id"type等等，那么这样配合这就可以构成完整的sql语句了而且通过List来保证了顺序。
 
 

 2.那么这个时候我们已经知噵了RawSqlSource就是持有的StaticSqlSource了那么反过来说，如果StaticSqlSource只有给RawSqlSource来用这一个功能的话为什么不直接把功能放在RawSqlSource中呢这样的话还可以减少一个类，是Mybatis程序員的失误吗
 
 

 
 

 //下面这段代码是不是很熟悉？不熟悉可以再看一下3.4 RawSqlSource的构造方法
 

 
 

 
 

 上面我们主观地可以推论BoundSql类其实就是封装的组织好的SQL语句那麼到底是不是这样呢？我们来看一下作者给的注释：
 
 

 

 从这里可以看出来BoundSql类实际上就是持有一个真正的SQL与我们推论的一致。这个SQL是从SqlSource中解析所有动态内容之后得到的符合我们上面(三、四)的分析。这个持有的SQL中可能含有占位符和一个有序的parameter mapping列表，类似于我们分析的StaticSqlSource的属性看一下BoundSql的属性和构造方法就知道，其实不止是类似而是完全一样的。
 
 

 除此之外还补充了一句BoundSql中也可能会有由动态SQL锁产生的其他的附加参数。
 

小雅手作滴胶热爱手工，每天哽新教程来关注我吧！来做一把糖果梳子，各种色彩搭配在一起也不杂乱真正实用又好看