mybatis递归查询_MyBatis#MyBatis映射体系-上（五）

MetaObject

首先来看一下MetaObject，在MyBatis中很多地方都是用到了MetaObjet，例如BaseExecutor、BeanWapper等，只要是对Java属性的操作基本上都会涉及到MetaObject。

那么MetaObject到底有什么作用？

首先看一下是用反射对一个Blog类的方法调用

@Test

我们发现这样写是很麻烦的，那是否有一个东西可以更简便的来对属性进行赋值等操作呢 ？

@Test

这只是一个简单的例子，至于MetaObject来说，里面的功能超级超级强大，比如说MetaObject还支持子属性中的子属性的赋值操作

@Test

@Test

@Test

@Test

@Test

@Test

总结：

1. 直接操作属性
2. 操作子属性
3. 自动创建属性对象
4. 自动查找属性名，支持下划线转驼峰
5. 基于索引访问数组

MetaObject的底层实现是BeanWapper，基本上带有Wapper的类的作用都是装饰器

BeanWapper只能操纵当前的属性，不能操作属性中的属性

MetaObject用于解析属性的表达式，例如：labels[res].name，BeanWapper的底层使用反射MetaClass用于处理反射操作

MetaObject的底层是Reflector反射器

MetaClass和Reflector的区别？

MetaClass可以操作属性下的子属性，例：可以获取labels[res].name的get方法
Reflector只能获取当前属性的get方法

MetaObject获取属性值流程

假如现在要获取某个博客下面的某一个评论的某一个评论者的名称

1. 首先判断表达式的下面是否还有子属性，如果有子属性，就先获取当前的自属性，再将当前的属性获取子属性，即将comments[0]转换成一个新的MetaObject，MetaObject( comments )

2. 继续获得下面的属性，如果要将其封装成MetaObject，那么就需要获取其对应的值，所以同样要调用getValue，此时通过comments调用

3. 拿到一个新的MetaObject

4. 拿到评论中的User信息

5. 同理，再经过一圈获取name属性

6, 此时不存在子属性，调用BeanWrapper.get()获取当前属性值，判断是否有集合索引？如果不存在则直接调用集合反射获取属性值

7. 如果存在集合索引，那么首先先获取集合索引（下标index），再基于索引获取集合中的值，例如：首先获取comments，得到一个List索引，在根据List获取想要得到的集合中的值comments[0]

下面结合源码来看一下上面所示的流程

@Test

PropertyTokenizer：属性分词器，即将表达式进行分词

例如，comments[0].user.name

name -> comments
indexedName -> comments[0]
index -> 0
children -> user.name

在获取children时，又会变成一个PropertyTokenizer，继续向下解析

1. 判断是否存在子属性

此时children = user.name

如果不存在子属性，例如直接查找ID

在本例中，是存在子属性的（user.name），所以需要把自属性转换成MetaObject

即如果获取的是一个数组，则会返回一个List

如果获取的是一个数组中的一个值，则会返回一个对应的对象

将返回的结果包装成一个MetaObject

可以看到，返回的MetaObject已经包装了Comment

紧接着继续获取子属性，此时prop.getChildren() = “user.name“，即再走一次循环

一下就是大致流程，让大家明白即可，就是一个递归过程。

根据user得到User值

再次循环，查询name，最终得到值

是不是有点蒙，大家可以试一下看着上面的流程图debug一下，多试几次就可以理解了

---

对于BeanWapper，我们可以模拟几个例子

public 

首先断点打到第一个get

如果有坐标说明是对集合的访问，那么接下来需要做两件事情。

1. 获取集合的List
2. 通过坐标获取List中具体的值

又回到了getValue方法

最后通过下标拿到返回值，底层是list.get(index)方法获取值

对于第二个get来说，其没有index下标值，则直接通过反射拿去相关的值

通过反射调用get和set方法、

---

ResultMap结果集映射

ResultMap的作用就是Java对象和表格行进行转化，即由属性名和数据库中列名进行对应

即就是将JavaBean中的属性指向数据库中的每一列

在ResultMap中进行映射操作，ResultMap#type表示映射到哪个JavaBean，所谓type就是JavaBean对应的Class，type中的多个属性对应表格行的多个列。那如何表达属性和列之间的关系？--- ResultMapping（其和ResultMap为一对多关系）

什么是ResultMapping？

<resultMap 

在resultMap中包含的部分都属于ResultMapping

ResultMapping表现形式：

association：一对一，类似于上面一个评论一个评论者
collection：一对多，类似于上面一个博客，一组评论

例：符合映射

<resultMap 

例：嵌套查询，如果设置了select，那么association中配置的id和result就失效了

<resultMap 

例：外部映射，如果设置了resultMap，那么select就不起作用了，并且如果同时设置运行时会报错

<resultMap 

缺点：手动映射写起来很麻烦，所以可以采用自动映射

自动映射

当属性名和列名相同时，将会触发自动映射，将其转换成UnMappedColumnAutoMapping，若属性名和列名相同时，我们同样手动设置了两者的关系，那么就自动忽略掉自动映射，优先以手动映射为主。

ResultSetMetaData可以获取列的总数、名称、类别、类型......

生成的UnMappedColumnAutoMapping类似于刚才说的ResultMapping，只不过UnMappedColumnAutoMapping没有关联字段和集合关联字段，即只有基本的转换映射操作

例子：

<mapper 

测试代码：

@Test

只查询出resultMap中所指出的字段

开启自动映射：

<resultMap 

因为author和comments都属于复杂属性，不能跟数据库的字段对应上，所以需要设置association

总之，最后resultMap中的所有属性都会转换成 ResultMap#ResultMapping

<mapper 

即通过association查询得到复杂属性

通过配置Collection可以将comments信息也查找出来

<mapper 

接下来就开始他们底层的原理到底是什么

---

嵌套子查询

首先搞清楚结构关系

查询评论时，同样需要查询用户，因为需要知道这个评论时谁写的

此时，如果步骤（1）的useId和步骤（2）的userId相等，就没有必要再次查询相同的userId，直接去一级缓存中查找即可

假设，现在在Comment中添加一个Blog属性，即Blog和Comments互相依赖

Q：在触发一级缓存时，是否会产生死循环？

例：

<mapper 

发现并不会触发死循环，MyBatis是如何解决这种问题的？

1. 延迟加载
2. 缓存占位符

循环依赖流程解析

在准备之后，判断一级缓存是否命中（通过延迟加载的方式）

即使一级缓存有值，也不填充进去，直到主查询结束之前再填充进去

如果没有命中一级缓存，判断是否需要懒加载，否则去进行实时加载

结合源码分析：

填充属性

只有手动填充时才会触发懒加载

获取嵌套查询的映射值：

延迟加载

在主查询结束后再填充属性值

从Cachekey中拿出缓存值，给MetaObject填充property属性

延迟加载的实现就是BaseExecutor中

DeferredLoad：判断当前这个类是否是可加载的，如果是可加载的，直接在缓存中拿出值然后setValue即可

当前缓存有值，且当前的值不等于当前的占位符，那就说明是可加载的

那么这些跟循环依赖有什么联系呢？

在查询时，有一个queryStack = 0

这个queryStack对应的就是当前查询栈的层级（对应图中的0、1、2）

接下来开始调试代码：

在查询数据库前，先给缓存的key添加一个占位符

接下来去查询数据库，然后解析结果集，在解析结果集时同时也会解析comment结果集，所以会触发comment查询操作，在getNestedQueryMappingValue中进行触发

在填充comment属性时，会触发缓存操作

此时，开始解析comment

此时comment没有缓存值，由于我们已经关闭了懒加载，所以去执行查询操作

查询操作：

通过Executor直接发球query操作，那么query操作就又会到达我们之前说的BaseExecutor的query操作

此时的query对应的是（1）comment

在comment中解析Blog

此时可以看到，缓存中已经有值了

此时缓存中存在的值就是一个占位符

之后进行延迟加载操作

可以看到所谓的延迟加载就是将其放入延迟加载的链表中

当查询返回值主查询中，再将延迟加载的值真正的放入其中

只有是占位符的情况下，才会延迟加载，否则缓存有的情况下就直接加载

在源码中可以发现，其在查询完数据库之后，将占位符删除，再存入真正的值

在查询完数据库之后，再将stack-1，就相当于回到了主查询

最后将延迟加载的值填充进去，完成了主流程

此时发现有三个延迟加载操作

总结：

通过一级缓存、延迟加载、占位符解决了循环依赖问题

这就是为什么有stack这个属性，为什么一级缓存不能关闭的原因（解决循环依赖）