（九） MyBatis从入门到入土——延迟加载、鉴别器以及继承

这是mybatis系列第9篇，没看前文的建议先去【Java冢狐】公众号中查看前文，方便理解和掌握。在上一篇中我们介绍了关于MyBatis的自动映射是如何开启以及使用的，想必大家对于这方面的知识有所了解了。

今天要给大家带来的主要是MyBatis延迟加载以及鉴别器相关方面的知识以及内容。

延迟加载

延迟加载介绍

所谓的延迟加载就是将数据加载时机推迟，其中比较典型的应用就是推迟嵌套查询的执行时机。

因为在mybatis中经常用到关联查询，但是并不是任何时候都需要立即返回关联查询结果。就比如查询订单信息，并不一定需要及时返回订单对应的用户信息或者订单详情信息等，所以当我们遇到这种情况时就需要一种机制，当需要查看关联的数据时，再去执行对应的查询，返回需要的结果。

这种需求在mybatis中可以使用延迟加载机制来实现。

延迟加载2种设置方式

MyBatis对于延迟加载提供了两种设置方式，分别是：

• 全局配置的方式
• sqlmap中配置的方式

从这两种方式的名称来看就能发现这两种延迟加载的区别，第一种方法会对所有的关联查询有效，而第二种方法只会对相关设置的查询有效。

下面我们就分别看一下这两种延迟加载的使用方式。

全局配置延迟加载

要想实现全局配置延迟加载就要通过mybatis的配置文件。

mybatis配置文件中通过下面两个属性来控制延迟加载：

<settings> <!--打开延迟加载的开关 --> <setting name="lazyLoadingEnabled" value="true"/> <!-- 当为true的时候，调用任意延迟属性，会去加载所有延迟属性，如果为false，则调用某个属性的时候，只会加载指定的属性 --> <setting name="aggressiveLazyLoading" value="false"/></settings>

• lazyLoadingEnabled：这个属性比较好理解，是否开启延迟加载，默认为false，如果需要开启延迟加载，将其设置为true
• aggressiveLazyLoading：当为true的时候，调用任意延迟属性，会去加载所有延迟属性，如果为false，则调用某个属性的时候，只会加载指定的属性

关于全局配置延迟加载的说明就是这些，下面我们来用一个具体的例子来说明下全局配置延迟加载是如何使用的。

需求

这次我们要使用MyBatis实现的需求就是通过订单id查询订单的各种信息，诸如：订单用户信息、订单明细列表。其中订单用户信息和订单明细信息采用延迟加载的方式来进行获取。

mybatis配置

按照前面的介绍第一步就是通过mybatis的配置文件来进行设置。如下所示：

<settings> <!--打开延迟加载的开关 --> <setting name="lazyLoadingEnabled" value="true"/> <!-- 当为true的时候，调用任意延迟属性，会去加载所有延迟属性，如果为false，则调用某个属性的时候，只会加载指定的属性 --> <setting name="aggressiveLazyLoading" value="true"/></settings>

上面的orderModelMap1元素下面有两个关联查询，我们也写一下。

对应的3个Model

上面我们写了三个

@[email protected]@[email protected]@[email protected] class OrderModel { private Integer id; private Integer userId; private Long createTime; private Long upTime; private UserModel userModel; //订单详情列表 private List<OrderDetailModel> orderDetailModelList;}@[email protected]@[email protected]@[email protected] class UserModel { private Integer id; private String name;}@[email protected]@[email protected]@[email protected] class OrderDetailModel { private Integer id; private Integer orderId; private Integer goodsId; private Integer num; private Double totalPrice;}

测试用例

写完了Model，我们的代码基本就大功告成了，接下来我们就来看一看延迟加载的使用效果。

com.zhonghu.chat09.demo5.Demo5Test#[email protected] void getById1() throws IOException { //指定mybatis全局配置文件 mybatisConfig = "demo5/mybatis-config.

运行输出

01:55.343 [main] DEBUG c.j.c.d.mapper.OrderMapper.getById1 - ==> Preparing: SELECT a.id , a.user_id, a.create_time, a.up_time FROM orders a WHERE a.id = ? 01:55.372 [main] DEBUG c.j.c.d.mapper.OrderMapper.getById1 - ==> Parameters: 1(Integer)01:55.431 [main] DEBUG c.j.c.d.mapper.OrderMapper.getById1 - <== Total: 101:55.431 [main] INFO c.j.chat05.demo5.Demo5Test - -------分割线--------01:55.432 [main] DEBUG c.j.c.d.m.O.getListByOrderId1 - ==> Preparing: SELECT a.id, a.order_id AS orderId, a.goods_id AS goodsId, a.num, a.total_price AS totalPrice FROM order_detail a WHERE a.order_id = ? 01:55.432 [main] DEBUG c.j.c.d.m.O.getListByOrderId1 - ==> Parameters: 1(Integer)01:55.435 [main] DEBUG c.j.c.d.m.O.getListByOrderId1 - <== Total: 201:55.439 [main] DEBUG c.j.c.d.mapper.UserMapper.getById1 - ==> Preparing: SELECT id,name FROM user where id = ? 01:55.439 [main] DEBUG c.j.c.d.mapper.UserMapper.getById1 - ==> Parameters: 2(Integer)01:55.441 [main] DEBUG c.j.c.d.mapper.UserMapper.getById1 - <== Total: 101:55.441 [main] INFO c.j.chat05.demo5.Demo5Test - UserModel(id=2, name=Java冢狐)

从日志中可以看出，总共有3次查询，后面2次查询在分割线之后出现的，说明是调用了orderModel.getUserModel()触发后面2次查询动作。

代码中我们调用的是获取用户信息，而订单列表信息也被加载了，这个主要是由于aggressiveLazyLoading被设置为true了，当使用到一个延迟加载的属性时，其他的延迟加载的属性也会被一起加载，所以触发了2个关联的查询。

下面我们看看将aggressiveLazyLoading设置为false的效果

<settings> <!--打开延迟加载的开关 --> <setting name="lazyLoadingEnabled" value="true"/> <!-- 当为true的时候，调用任意延迟属性，会去加载所有延迟属性，如果为false，则调用某个属性的时候，只会加载指定的属性 --> <setting name="aggressiveLazyLoading" value="false"/></settings>

再次运行测试用例输出

12:19.236 [main] DEBUG c.j.c.d.mapper.OrderMapper.getById1 - ==> Preparing: SELECT a.id , a.user_id, a.create_time, a.up_time FROM orders a WHERE a.id = ? 12:19.268 [main] DEBUG c.j.c.d.mapper.OrderMapper.getById1 - ==> Parameters: 1(Integer)12:19.336 [main] DEBUG c.j.c.d.mapper.OrderMapper.getById1 - <== Total: 112:19.337 [main] INFO c.j.chat05.demo5.Demo5Test - -------分割线--------12:19.338 [main] DEBUG c.j.c.d.mapper.UserMapper.getById1 - ==> Preparing: SELECT id,name FROM user where id = ? 12:19.338 [main] DEBUG c.j.c.d.mapper.UserMapper.getById1 - ==> Parameters: 2(Integer)12:19.340 [main] DEBUG c.j.c.d.mapper.UserMapper.getById1 - <== Total: 112:19.341 [main] INFO c.j.chat05.demo5.Demo5Test - UserModel(id=2, name=Java冢狐)

通过这两次对比，我们可以很轻易的看出延迟加载开启与否的效果区别。

sqlmap中设置延迟加载

上面的篇幅我们介绍了全局的延迟加载是如何起作用以及如何使用的。全局的方式会对所有的关联查询起效，影响范围比较大，mybatis也提供了在关联查询中进行设置的方式，只会对当前设置的关联查询起效。

关联查询，一般我们使用association、collection，这两个元素都有个属性fetchType，通过这个属性可以指定关联查询的加载方式。

fetchType有两个值

• eager：立即加载
• lazy：延迟加载

下面我们来实现一个需求：还是通过订单id查询订单信息，并获取关联的用户信息、订单详细列表，用户信息我们要求立即加载，而订单详情我们要求延迟加载。

重点注意上面配置中association、collection这2个元素的fetchType属性，eager表示立即加载，lazy表示延迟加载。

测试用例

com.zhonghu.chat09.demo5.Demo5Test#[email protected] void getById2() throws IOException { //指定mybatis全局配置文件 mybatisConfig = "demo5/mybatis-config2.

运行输出

36:54.284 [main] DEBUG c.j.c.d.mapper.OrderMapper.getById2 - ==> Preparing: SELECT a.id , a.user_id, a.create_time, a.up_time FROM orders a WHERE a.id = ? 36:54.321 [main] DEBUG c.j.c.d.mapper.OrderMapper.getById2 - ==> Parameters: 1(Integer)36:54.385 [main] DEBUG c.j.c.d.mapper.UserMapper.getById1 - ====> Preparing: SELECT id,name FROM user where id = ? 36:54.385 [main] DEBUG c.j.c.d.mapper.UserMapper.getById1 - ====> Parameters: 2(Integer)36:54.387 [main] DEBUG c.j.c.d.mapper.UserMapper.getById1 - <==== Total: 136:54.389 [main] DEBUG c.j.c.d.mapper.OrderMapper.getById2 - <== Total: 136:54.390 [main] INFO c.j.chat05.demo5.Demo5Test - -------分割线--------36:54.392 [main] DEBUG c.j.c.d.m.O.getListByOrderId1 - ==> Preparing: SELECT a.id, a.order_id AS orderId, a.goods_id AS goodsId, a.num, a.total_price AS totalPrice FROM order_detail a WHERE a.order_id = ? 36:54.392 [main] DEBUG c.j.c.d.m.O.getListByOrderId1 - ==> Parameters: 1(Integer)36:54.397 [main] DEBUG c.j.c.d.m.O.getListByOrderId1 - <== Total: 236:54.398 [main] INFO c.j.chat05.demo5.Demo5Test - [OrderDetailModel(id=1, orderId=1, goodsId=1, num=2, totalPrice=16.00), OrderDetailModel(id=2, orderId=1, goodsId=1, num=1, totalPrice=16.00)]

注意输出中的分割线，可以分析得出，用户信息是和订单信息一起立即查出来的，而订单详情，是在我们调用orderModel.getOrderDetailModelList()获取订单列表的时候，采取懒加载的。

鉴别器(discriminator)

有时候，一个数据库查询可能会返回多个不同的结果集（但总体上还是有一定的联系的）， 鉴别器（discriminator）元素就是被设计来应对这种情况的，鉴别器的概念很好理解——它很像 Java 语言中的 switch 语句。

discriminator标签常用的两个属性如下：

• column：该属性用于设置要进行鉴别比较值的列。
• javaType：该属性用于指定列的类型，保证使用相同的java类型来比较值。

discriminator标签可以有1个或多个case标签，case标签有一个比较重要的属性：

• value：该值为discriminator指定column用来匹配的值，当匹配的时候，结果会走这个case关联的映射。

我们使用鉴别器实现一个功能：通过订单id查询订单信息，当传入的订单id为1的时候，获取订单信息及下单人信息；当传入的订单id为2的时候，获取订单信息、下单人信息、订单明细信息；其他情况默认只查询订单信息。

注意上面的discriminator，这部分是关键，discriminator内部的case会和每行查询结果中的id字段进行匹配，匹配成功了case内部的关联查询会被执行，未匹配上的，只会走discriminator外部默认配置的映射映射规则。