Mybatis(七) - 结果集的封装与映射

上一章，我们把动态 SQL 的生成，以及 PreparedStatement 参数绑定的过程都研究明白了，对于 DML 来讲，只需要最后拿到影响结果的行数就可以，但对于 DQL 来讲，另一个很关键的过程，就是结果集的封装。

本章我们来着重探讨 MyBatis 如何对结果集进行封装和映射的。

在 Executor 执行查询时， prepareStatement 的动作完成后，下面就是实际的查询动作了：

public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, 
        ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
    Statement stmt = null;
    try {
        Configuration configuration = ms.getConfiguration();
        StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
        stmt = prepareStatement(handler, ms.getStatementLog());
        return handler.query(stmt, resultHandler);
    } finally {
        closeStatement(stmt);
    }
}

StatementHandler 负责了发起查询的动作，它的 query 方法中会真正的调用 PreparedStatement 的 execute 方法，向数据库发起查询动作：

public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
    PreparedStatement ps = (PreparedStatement) statement;
    ps.execute();
    return resultSetHandler.handleResultSets(ps);
}

发起请求动作后，下面会使用一个 ResultSetHandler 去处理结果集，这个方法就是本章要深入探讨的了，本章我们从这里出发。

1. ResultSetHandler

我们先简单了解一下这个 ResultSetHandler 是啥。跟其他 Handler 的设计一样，ResultSetHandler 同样是个接口：

虽说是有三个方法，但第二个是跟 Cursor 有关，第三个跟存储过程有关，我们都不关心，最重要的还是 handleResultSets ，也就是上面我们看到 StatementHandler 调用的方法。

它的实现类，在 MyBatis 中就一个：DefaultResultSetHandler ，我们可以先简单过一遍它内部的成员：

上面的几个成员都是老生常谈的，组合在 ResultSetHandler 中也是很正常的，注意底下还有一个 autoMappingsCache ，各位小伙伴可以先记住它，下面我们会看到的。

OK ，下面我们开始走 handleResultSets 的逻辑。

2. handleResultSets

这个方法本身不算很长，所以小册不打算一上来就拆解为多段，先整体看一下，有一个大概的脉络认识：

纵观整段逻辑，其实它要干的活，就是解析 Statement 中的所有 ResultSet ，并封装结果集，说白了，这里做的主要工作不是干实际的活，而只是循环调度而已，毕竟 MyBatis 本身支持我们调用存储过程，所以这里会对存储过程中返回的多个不同类型的结果集予以兼容。不过从实际使用的角度来看，我们还是使用单个 select 动作的场景为主，几乎不会使用存储过程，所以这里我们不对存储过程的相关逻辑予以展开。

接下来，小册针对上面提到的几个关键步骤，逐一展开。

2.1 包装ResultSetWrapper

ResultSet 本身是原生 jdbc 的东西，包装为 ResultSetWrapper 肯定是在此基础上增强一些便捷的操作。我们先看看它包装的动作：

获取完成后，直接封装为 ResultSetWrapper ，返回，逻辑非常朴实无华。但是吧，按照 MyBatis 一贯的尿性，ResultSetWrapper 的初始化，也就是构造方法中，一定有很重要的逻辑，所以我们得去看一眼。

2.1.1 ResultSetWrapper的构造方法

构造方法中藏了一个初始化的动作，我们要重点关注一下：

注意看，ResultSetWrapper 拿到 ResultSet 后，会先操作它获取 ResultSetMetaData ，这个家伙是原生 jdbc 的东西，它可以获取到关于 ResultSet 对象中列的类型和属性信息，正好 MyBatis 要封装结果集时，就得拿这些信息，所以这里有一系列的获取动作。获取完成后，它会存放到 ResultSetWrapper 的几个成员中：

因为都是 List ，所以它们的位置也一一对应，这样收集好了，下面再用到的时候就不用重复操作 ResultSet 了。

2.1.2 getTypeHandler

ResultSetWrapper 中有一个比较重要的方法 getTypeHandler ，它可以获取到指定类型的 TypeHandler 对象，利用 TypeHandler 可以实现从结果集中取指定类型的数据。这个方法在下面 ResultSetHandler 中有一个重要的使用位置，我们可以先来扫一遍它的实现：

自上往下走完一遍，我们能很清楚的感受到一个事情：这个 getTypeHandler 是尽力的帮我们去处理结果集中每一个列的封装处理了，这样做的目的也很明确，MyBatis 希望给我们做结果集映射的时候，做到每一列都能用最准确的类型去封装和处理。

2.2 获取映射规则

回到 ResultSetHandler 中，上面封装好 ResultSetWrapper 后，下面的一个最最重要的动作，就是获取映射规则，以及封装实际的数据了。这个步骤相当难，小伙伴们一定要好好静下心来看。

2.2.1 ResultMaps里有什么

首先我们来看 List<ResultMap> resultMaps = mappedStatement.getResultMaps(); 这句代码，它会从 MappedStatement 中获取到 ResultMap 的一个集合。不同的场景下取到的东西不一样，我们分别来看。

2.2.1.1 resultType

以前面我们 Debug 测试时用的 dynamic.findAllDepartment 来看，Debug 至此时，可以发现它特别简陋：

img

阿这？底下的好多属性都是空的，就保存了一个 id 一个 type ，没了？合着用 resultType 的方式就保存这么点？还真是，下面我们看处理过程的时候，就会意识到，其实这么点就够了。

2.2.1.2 resultMap

上面调用的 dynamic.findAllDepartment ，本身是用 resultType 接收返回结果集的，但如果是 resultMap 呢？我们拿 mybatis-03-mapper 工程的 com.linkedbear.mybatis.mapper.UserMapper.findAllLazy 测试：

再次 Debug ，在断点处观察获取到的 resultMaps 如下：

img

好家伙，这可真全啊，要映射的属性、列名，以及封装的一个一个 ResultMapping 全部都在里面，后面我们可要好好地看这部分啊。

2.2.2 处理单个映射结果集

接下来就是重头戏 handleResultSet 方法了，它用来处理单个结果集的映射，也就是上面 resultMaps 集合中的每一个映射规则。通常情况下，这个集合中只会有一个元素，所以处理结果集的动作也只会执行一次。

好，下面我们来看方法的实现：

前面关于存储过程的部分我们就不看了，重点是下面的 else 部分，这里面它会先判断一下 ResultSetHandler 中是否有内置的 resultHandler ，然而通过 Debug 发现并没有：

img

为什么没有呢？一路向上爬，最终发现是我们调用 SqlSession 的 selectList 方法中，传入的 Executor.NO_RESULT_HANDLER 本身是个 null 。。。

那好吧，人家 MyBatis 自己就没指望我们自己传 ResultHandler ，那我们也甭费心了，直接研究默认实现就 OK 。

这个 ResultHandler 跟着其余的参数，进入到了下面的 handleRowValues 方法，我们继续往下看。

2.2.3 handleRowValues

这里面有一个先行的判断需要各位注意：

注意源码的注释中提到了一个 “嵌套 resultMap ” 的概念，什么是嵌套 resultMap 呢？其实之前我们都写过很多了，比方说下面两种：

这两种方式，都是在实际查询的时候，多查出一些字段，在映射结果集时，将一些多余的列数据放入实体类中组合的其他类中，从而形成嵌套模型类，反映到结果集的映射上，就是嵌套结果集。

注意，延迟加载的属性不属于嵌套 resultMap ：

我们先来看单层的 resultMap 如何封装，继续往下走。

2.2.4 handleRowValuesForSimpleResultMap

源码中先把每个关键步骤都标注上注释，各位先有个整体的印象：

呦，这个方法中终于看到 ResultSet 的真身了，那是不是就意味着从 ResultSet 中取数据的动作真的来了呢？答案是肯定的！我们赶紧来分步看看这里都干了什么吧！

2.2.4.1 DefaultResultContext

这个家伙的出现，是不是让各位想起来了 DynamicContext 呢？哎，确实有那么一点点的味道，但这个 DefaultResultContext 的设计相当的简单：

这三个属性似乎乍一看会让我们感觉多余，不要着急，后面各位会看到它的必要性的。

2.2.4.2 内存分页

MyBatis 设计的超级没用之一的地方就是这个内存分页，我们貌似从来都没用过它。不过出于尊重，我们还是看一看吧。

看，多么的朴实无华。。。就是一行一行的跳数据。。。这种用法需要我们必须查出全部的数据来，才能进行内存分页，但这样的话性能是不是有点太。。。所以你懂得，我们都不用，这里大家知道一下就得了。

2.2.4.3 鉴定器的决定

鉴定器是干啥的各位还记得吧，它可以根据结果集的某一行数据，决定使用哪个 ResultMap 去实际的映射结果集，它的实现原理如下：

2.2.4.4 获取一行数据的值并映射为对象

得到最终可用的 resultMap 后，下面终于来到获取值和映射对象的过程了！这个方法本身也是稍微复杂一些，我们先看一下方法总体逻辑：

自上而下走完流程之后，一行数据也就封装完毕了，这里面涉及到的几个比较复杂的方法我们再展开看一看。

2.2.4.4.1 创建空对象

要封装结果集，肯定要先有一个空的模型类对象，或者空的 Map 才可以吧，这一步就是先把 “空壳” 创建出来。这个 createResultObject 里面设计的逻辑比较复杂，小册不把源码都贴出来了，只粘出一些重要的逻辑片段，各位看一下就 OK 了：

四种方式都可以创建出空对象，一般情况下我们使用的实体类都是带默认无参构造器的，所以都是走第三种方式，借助 ObjectFactory 创建对象。

2.2.4.4.2 未声明的属性自动映射

创建出空对象之后，接下来就该处理属性映射了。下面的 applyAutomaticMappings 方法是处理自动映射，说到这个自动映射，我们要提一下上面的那个伏笔了。使用 resultType 声明结果集接收类型时，我们发现经过封装后的 resultMap 对象中属性值好少，只记录了 Class 类型的信息，这个时候 MyBatis 就觉得，既然你只告诉我类型，那我就按照属性名和列名一一对应的方式，处理属性映射和赋值了。

下面我们来看看方法的实现，本身逻辑不复杂，快速过一遍即可：

哦，合着逻辑就是 “解析列 → 获取值 → 反射 set 值” ，一套连招完事啊，那逻辑确实简单。不过这里面有两个细节我们可以关注一下。

一个是自动映射的列，这个获取的依据是什么呢？

还记得上面封装 ResultSetWrapper 的时候，它在构造方法中获取了 ResultSet 的所有列名吗？这个地方获取的列名，会保存在一个属性名为 columnNames 的集合中。换言之，查询返回的结果集中有哪些列，这里需要自动映射的列就有哪些。

另一个小细节是 TypeHandler 获取值，它是怎么获取的呢？

很简单，MyBatis 本身是对原生 jdbc 进行的封装，所以底层肯定是操作 ResultSet 的方法了。我们以其中一个为例看一下：

经过这个方法的处理后，如果结果集类型是用 resultType 封装的，那就大功告成了。

2.2.4.4.3 处理显式声明的属性映射

如果是使用 resultMap 呢？我们知道用 resultMap 声明的结果集，需要对属性的映射一一声明，也就是显式的声明。这个 applyPropertyMappings 方法就是对付这些 resultMap 映射的，方法比较长，各位只需要看其中标有注释的步骤即可：

可以看到，这个处理的大体思路，跟处理 resultType 的基本相仿呀，都是获取属性 → 从 ResultSet 中取值 → 反射设置值。

经过这一大串的处理后，一行数据就全部封装好了。

2.2.4.5 映射后的对象放入集合额

一行数据封装完成后，下一步自然是放入即将返回的集合中。这个处理本身难度不高，但是有点绕，小伙伴们集中注意力哦。

storeObject 方法往下调用到 callResultHandler 方法中，这个方法有两个动作，小心这个绕过来绕过去的动作哈。

首先是 nextResultObject ，它会将本次封装好的一行数据存入 ResultContext 中，并且给下标索引 + 1 ：

存入 resultObject 还可以理解，这个下标 + 1 的用意为何呢？

别忘了，MyBatis 有个内存分页，比方说我只想查 10 条，那这个下标索引到 10 的时候，你 ResultSet 后面有再多的数据，对不起我不管了，我走了。所以这个地方的索引值是为了内存分页。

至于后面的 ResultHandler.handleResult 方法，那就更简单了，它就是往 List 中放入一个对象：

如此循环，处理完毕后，结果集的封装也就基本完成了。

2.3 决定返回的元素类型

最后的最后，还有一个小小的动作：

诶？这是为何呢？为什么还要检查一下 multipleResults 的集合大小呢？是这样，MyBatis 本身支持对存储过程的处理，这个 multipleResults 本身就是考虑到可能一个存储过程中会返回多个结果集，所以这里有一个兜底处理，如果返回的结果集封装不止一个，那就说明我们走存储过程了。这个描述比较抽象，我们可以用一个很简单的图来解释一下：

img

一般情况下我们调用单次的查询，返回的都是这样一个家伙，但是我们根本不需要外层的那个 List ，所以 MyBatis 会在最后帮我们判断一下这个 multipleResults 集合的大小，如果只有一个 List ，那就直接扒出内层的返回给我们，完事。

经过漫长的处理，终于结果集的封装和映射的逻辑也走完了，一次完整的查询动作也就结束了。

上一页Mybatis下一页Java FrameWorks

最后更新于

这有帮助吗？