映射工具MetaObject
所谓映射是指结果集中的列填充至JAVA Bean属性。这就必须用到反射，而Bean的属性多种多样的有普通属性、对象、集合、Map都有可能。为了更加方便的操作Bean的属性，MyBatis提供了MetaObject 工具类，用于操作数据库中表的字段映射成 Java 对象的属性。它提供了一些方法来获取、设置、判断 Java 对象的属性。
基本功能
其具体功能如下：
查找属性：勿略大小写，支持驼峰、支持子属性 如：“blog.comment.user_name”
获取属性
基于.获取子属性 “user.name”
基于索引获取列表值 “users[1].id”
基于key获取map值 “user[name]”
设置属性：
可设置子属性值
支持自动创建子属性(必须带有空参构造方法，且不能是集合)
主要方法有:
getGetter(String name):获取属性的 getter 方法
getSetter(String name):获取属性的 setter 方法
getGetterType(String name):获取属性的类型
hasGetter(String name):判断是否有 getter 方法
hasSetter(String name):判断是否有 setter 方法
getValue(String name):获取属性的值
setValue(String name, Object value):设置属性的值
findProperty(String name, boolean useCamelCaseMapping):寻找属性,可以指定是否使用驼峰命名法(返回的是String类型)
public class User {
private int id;
private String name;
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
MetaObject metaObject = MetaObject.forObject(user);
// 获取 getter 方法
Method idGetter = metaObject.getGetter("id");
// 获取 setter 方法
Method nameSetter = metaObject.getSetter("name");
// 获取 name 属性的值
String name = (String) metaObject.getValue("name");
// 设置 id 属性的值
metaObject.setValue("id", 1);
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
底层结构
为了实现上述功能，MetaObject 相继依赖了BeanWrapper、MetaClass、Reflector。这四个对象关系如下：
BeanWrapper: 功能与MeataObject类似，不同点是BeanWrapper只能针对单个当前对象属性进行操作，不能操作子属性。
所以说Metaobject在查找一个属性的属性时，它会递进式的查找属性，再查找属性的属性，这个过程就是通过BeanWrapper查找的，Metaobject用来解析表达式
而BeanWrapper其底层一定是基于反射的，这里就借助了MetaClass
MetaClass ：类的反射功能支持，能获取整完整类的属性，包括属性的属性，其底层基于Reflector 。
Reflector ：类的反射功能支持，仅支持当前类的属性。
获取属性值的流程
对象结构如下图：
获取博客的第一个评论者的名称，其获取表达式是：
"comments[0].user.name"
MetaObjbt 解析获取流程如下图：
我们可以从这个流程中看到，MetaObject会使用递归将表达式一层层的解析，直到不存在子属性的时候才会将真正的获取工作交给BeanWrapper，BeanWrapper其底层再基于反射拿到属性值。
如果涉及到集合索引，则先获取集合，在基于索引获取集合中的值。这一部分的工作交给了BaseWrapper。
流程中方法说明：
MetaObject.getValue()：获取属性的值，首先根据属性名"comments[0].user.name" 解析成PropertyTokenizer，并基于属性中的“.” 来判断是否为子属性值，如果是就递归调用getValue()获取子属性对象。然后在递归调用getValue()获取子属性下的属性。直到最后的name属性。
MetaObject.setValue()：流程与getValue()类似，不同在于如果子属性不存在，则会尝试创建子属性。
我们结合一下源码：
我们可以看到MetaObject中表达式的解析其实依赖的是一个叫做PropertyTokenizer的属性分词器。
然后这个分词器有一个next方法，根据children生成分词器，以此来达到层层解析的效果。
集合这里使用的是BeanWrapper的get方法：
ResultMap结果集映射
映射是指返回的ResultSet列与Java Bean 属性之间的对应关系。通过ResultMapping进行映射描述，在用ResultMap封装成一个整体。
手动映射
映射设置
一个ResultMap 中包含多个ResultMapping 表示一个具体的JAVA属性到列的映射，其主要值如下：
ResultMapping 有多种表现形式如下：
constructor:构建参数字段
id：ID字段
result：普通结构集字段
association：1对1关联字段(关联一个对象的时候)
Collection：1对多集合关联字段
说一说这里的constructor：
resultMap中的constructor元素用于在结果集映射过程中调用类的构造方法。
当MyBatis构建结果对象时，默认会通过默认构造方法实例化目标类，然后通过setter方法为其赋值。
但是，有时我们的类没有默认构造方法，或者需要通过构造方法设置某些默认值，这时候constructor元素就很有用了。
我们可以在resultMap中配置constructor，指定目标类的构造方法，MyBatis在构建结果对象时就会调用这个构造方法。
constructor的配置语法如下:
1
2
3
4
idArgumnet：指定构造方法中用于id的那个参数。
arg：指定构造方法中的普通参数。
index：指定参数在构造方法参数列表中的位置。
javaType：指定参数的java类型。
那么MyBatis在构建结果对象时，会找一个匹配的构造方法，通过idArgumnet指定的id参数和arg指定的各个参数来调用构造方法并实例化对象。
举个例子,我们有一个用户类User:
public class User {
private int id;
private String name;
public User(int id, String name) {
this.id = id;
this.name = name;
}
}
1
2
3
4
5
6
7
8
9
我们的resultMap可以配置为:
1
2
3
4
5
6
那么MyBatis在处理结果集并映射为User对象时，会找到User(int, String)构造方法，并调用User(1, "Tom")来实例化User对象。
而如果没有配置constructor，MyBatis会默认调用无参构造User()来实例化，然后通过setter方法为id和name赋值，代码如下:
User user = new User();
user.setId(1);
user.setName("Tom");
1
2
3
可以看出，使用constructor具有一定的性能优势，并且可以避免无参构造方法的情况。
所以，constructor元素为resultMap的结果对象构建过程提供了更丰富的选择，我们可以根据自己的需要选择使用默认构造+setter方法或构造方法来实例化结果对象。这再一次体现了MyBatis灵活性的强大。
自动映射
当前列名和属性名相同的情况下，可使用自动映射
自动映射条件
列名和属性名同时存在（勿略大小写、驼峰-下划线）
当前列未手动设置映射
属性类别存在TypeHandler
开启autoMapping （默认开启）
自动映射只有在左边三种情况下可以成立，一旦涉及复杂的映射就不行了：
嵌套子查询
我们先来说说嵌套子查询的由来：
关联（association）元素处理“有一个”类型的关系。 比如，在我们的示例中，一个博客有一个用户。关联结果映射和其它类型的映射工作方式差不多。 你需要指定目标属性名以及属性的javaType（很多时候 MyBatis 可以自己推断出来），在必要的情况下你还可以设置 JDBC 类型，如果你想覆盖获取结果值的过程，还可以设置类型处理器。
关联的不同之处是，你需要告诉 MyBatis 如何加载关联。MyBatis 有两种不同的方式加载关联（当然Collection也可以使用）：
嵌套 Select 查询：通过执行另外一个 SQL 映射语句来加载期望的复杂类型。
就是这么简单。我们有两个 select 查询语句：一个用来加载博客（Blog），另外一个用来加载作者（Author），而且博客的结果映射描述了应该使用 selectAuthor 语句加载它的 author 属性。
其它所有的属性将会被自动加载，只要它们的列名和属性名相匹配。
这种方式虽然很简单，但在大型数据集或大型数据表上表现不佳。这个问题被称为“N+1 查询问题”。 概括地讲，N+1 查询问题是这样子的：
你执行了一个单独的 SQL 语句来获取结果的一个列表（就是“+1”）。
对列表返回的每条记录，你执行一个 select 查询语句来为每条记录加载详细信息（就是“N”）。
这个问题会导致成百上千的 SQL 语句被执行。有时候，我们不希望产生这样的后果。
好消息是，MyBatis 能够对这样的查询进行延迟加载，因此可以将大量语句同时运行的开销分散开来。 然而，如果你加载记录列表之后立刻就遍历列表以获取嵌套的数据，就会触发所有的延迟加载查询，性能可能会变得很糟糕。
嵌套结果映射：使用嵌套的结果映射来处理连接结果的重复子集。
但很多时候对象结构， 是树级程现的。即对象中包含对象。可以通过子查询获取子对象属性。
当依次解析Blog中的属性时，会先解析填充普通属性，当解析到复合对象时，就会触发对子查询。
循环依赖
两个对象之间互相引用即循环引用，如下图就是一个例子：
对应ResultMap如下：
这种情况会导致解析死循环吗？答案是不会。DefaultResultSetHandler 在解析复合映射之前都会在上下文中填充当前解析对象（使用resultMapId做为Key）。如果子属性又映射引用了父映射ID，就可以直接获取不需要在去解析父对象。具体流程如下：
具体代码：
懒加载
懒加载是为改善，解析对象属性时大量的嵌套子查询的并发问题。设置懒加载后，只有在使用指定属性时才会加载，从而分散SQL请求。
1
2
3
4
在嵌套子查询中指定 fetchType=“lazy” 即可设置懒加载。在调用getComments时才会真正加载。此外调用：“equals”, “clone”, “hashCode”, “toString” 均会触发当前对象所有未执行的懒加载。通过设置全局参数aggressiveLazyLoading=true ，也可指定调用对象任意方法触发所有懒加载。
set覆盖 &序列化
当调用setXXX方法手动设置属性之后，对应的属性懒加载将会被移除，不会覆盖手动设置的值。
当对象经过序列化和反序列化之后，默认不再支持懒加载。但如果在全局参数中设置了configurationFactory类，而且采用JAVA原生序列化是可以正常执行懒加载的。其原理是将懒加载所需参数以及配置一起进行序列化，反序列化后在通过configurationFactory获取configuration构建执行环境。
configurationFactory 是一个包含 getConfiguration 静态方法的类
public static class ConfigurationFactory {
public static Configuration getConfiguration() {
return configuration;
}
}
1
2
3
4
5
原理
MyBatis提供了association和collection两个标签来配置懒加载,它们的工作原理如下:
association或collection标签配置了fetchType="lazy"时,MyBatis会在查询结果中返回该属性的代理对象。这个代理对象包含了目标属性的数据加载逻辑。
当我们第一次调用代理对象的getter方法时,代理对象会自己去执行查询加载真实的数据,并将自己替换为真实的数据对象。
之后再调用getter方法则会直接返回真实的数据对象。
这样就实现了属性的懒加载,只有在真正需要用到该属性时才会执行查询加载数据。
我们来看个例子:
用户和账户的配置:
select * from user where id = #{id}
select * from account where user_id = #{id}
1
2
3
4
5
6
7
8
9
10
11
测试代码:
User user = mapper.selectUserById(1);
// 第一次调用account属性的getter方法
Account accout = user.getAccount();
1
2
3
当执行selectUserById(1)时,会查询出User对象,其account属性会被填充为一个代理对象。
当第一次调用user.getAccount()时,代理对象会执行selectAccountByUserId查询真实的Account数据,并将自己替换为真实的Account对象。
之后再调用getAccount()就会直接返回Account对象。
那么问题来了,这个代理对象是什么?它是如何知道要执行哪个select语句的?
MyBatis使用了JDK动态代理并增强了InvocationHandler来实现懒加载。当fetchType=lazy时,MyBatis会创建以下代理对象:
Proxy.newProxyInstance(
mapperInterface.getClassLoader(),
new Class[] { mapperInterface },
new LazyLoaderHandler(sqlSession, selectStatement)
)
1
2
3
4
5
LazyLoaderHandler实现了InvocationHandler接口,它知道实际要执行的select语句。
当调用getter方法时,实际会调用InvocationHandler的invoke方法。
invoke方法会先判断属性是否已经被加载,如果未加载则会通过SqlSession执行select语句查询数据,并将结果设置到源对象中。
之后再调用invoke方法就会直接返回已经加载的数据。
所以总结来说,MyBatis懒加载的原理是:
通过JDK动态代理生成包含懒加载逻辑的代理对象。
当第一次调用getter方法时,通过代理对象执行select语句查询数据。
将查询结果设置至源对象,并返回该结果。
之后再调用getter方法将直接返回结果,实现懒加载。
JDK动态代理是MyBatis懒加载功能的基础,MyBatis通过增强InvocationHandler来实现懒加载的代理效果。这是MyBatis这项功能的巧妙实现之处。
懒加载让我们可以将关联属性的加载延后到真正需要使用它的时候,这大大提高了数据库交互的效率,同时也减少内存的消耗。它是MyBatis优化数据库性能的重要手段之一。
内部结构
代理之后Bean会包含一个MethodHandler，内部在包含一个Map用于存放待执行懒加载，执行前懒加载前会移除。LoadPair用于针对反序列化的Bean准备执行环境。ResultLoader用于执行加载操作，执行前如果原执行器关闭会创建一个新的。
特定属性如果加载失败，不会在进行二次加载。
Bean代理过程
代理过程发生在结果集解析 交创建对象之后(DefaultResultSetHandler.createResultObject)，如果对应的属性设置了懒加载，则会通过ProxyFactory 创建代理对象，该对象继承自原对象,然后将对象的值全部拷贝到代理对像。并设置相应MethodHandler（原对象直接抛弃）
联合查询和嵌套映射
映射说明
映射是指返回的ResultSet列与Java Bean 属性之间的对应关系。通过ResultMapping进行映射描述，在用ResultMap封装成一个整体。映射分为简单映射与复合嵌套映射。
简单映射：即返回的结果集列与对象属性是1对1的关系，这种情况下ResultHandler 会依次遍历结果集中的行，并给每一行创建一个对象，然后在遍历结果集列填充至对象的映射属性。
嵌套映射：但很多时候对象结构， 是树级程现的。即对象中包含对象。与之对应映射也是这种嵌套结构。
在配置方式上可以直接配置子映射，也以引入外部映射和自动映射。共有两类嵌套结构分别是:
一对多
多对多
关于映射的使用方式，官网有非常详细的文档。这里就不在赘述。接下来分析一下，嵌套映射结果集填充过程。
联合查询
有了映射之后如何获取结果？普通的单表查询是无法获取复合映射所需结果，这就必须用到联合查询。然后在将联合查询返回的数据列，拆分给不同的对象属性。1对1与1对多拆分和创建的方式是一样的。
1对1查询映射
select a.id,
a.title,
b.id as user_id,
b.name as user_name
from blog a
left join users b on a.author_id=b.id
where a.id = 1;
1
2
3
4
5
6
7
通过上述语句联合查询语句，可以得出下表中结果。结果中前两字段对应Blog，后两个字段对应User。然后在将User作为author属性填充至Blog对象。
上述两个例子中，每一行都会产生两个对象，一个Blog父对象，一个User子对象。
1对多查询
select a.id,a.title,
c.id as comment_id,
c.body as comment_body
from blog a
left join comment c on a.id=c.blog_id
where a.id = 1;
1
2
3
4
5
6
上述语句可得出三条结果，前两个字段对应Blog，后两个字段对应Comment(评论)。与1对1不同的是，三行指向的是同一Blog。因为它ID都是一样的。
上述结果中，相同的三行Blog将会创建一个Blog，同时分别创建三个不同的Comment组成一个集合，并填充至comments对象。
RowKey创建机制
在1对多的查询过程中，是基于RowKey来断定两行数据是否相同的 。RowKey一般基于。但有时并不会指定 这时将会采用其它映射字段创建RowKey具体规则如下：
结果集解析流程
这里直接采用1对多的情况进行解析，因为1对1就是1对多的简化版。查询的结果如下表：
其整个解析流程如下图：
流程说明：
所有映射流程的解析都是在DefaultResultSetHandler当中完成。主要方法如下：
handleRowValuesForNestedResultMap()：嵌套结果集解析入口，在这里会遍历结果集中所有行。并为每一行创建一个RowKey对象。然后调用getRowValue()获取解析结果对象。最后保存至ResultHandler中。
注：调用getRowValue前会基于RowKey获取已解析的对象，然后作为partialObject参数发给getRowValue
getRowValue()：该方法最终会基于当前行生成一个解析好对象。具体职责包括，1.创建对象、2.填充普通属性和3.填充嵌套属性。在解析嵌套属性时会以递归的方式在调用getRowValue获取子对象。最后一步4.基于RowKey 暂存当前解析对象。
如果partialObject参数不为空 只会执行 第3步。因为1、2已经执行过了。
applyNestedResultMappings()：解析并填充嵌套结果集映射，遍历所有嵌套映射,然后获取其嵌套ResultMap。接着创建RowKey 去获取暂存区的值。然后调用getRowValue 获取属性对象。最后填充至父对象。
如果通过RowKey能获取到属性对象，它还是会去调用getRowsValue，因为有可能属下还存在未解析的属性。
————————————————
版权声明：本文为CSDN博主「十八岁讨厌编程」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zyb18507175502/article/details/130869546
