iBatis查询复杂集合
本文系iBatis开发详解系列文章之在iBatis查询复杂集合
通常我们使用iBatis的select查询都是映射的简单对象，即便在一个查询中连接多个表也是如此，那么既然iBatis是SQL Mapper，也就是说它可以映射复杂集合，我们来看看如何让对象模型向数据模型（关系型数据模型）靠拢。
假设在在线购物应用中，我们有用户表User，订单表Order和订单项表OrderItem，它们之间存在的关联是显而易见的。用户可以下订单，而订单中可以包含多个项。
我们的数据库设计如下：
我们使用各个属性连描述orderItem表的字段，下面是order对象：
使用数组来存放每个订单的订单项，分别给出setter和getter方法。下面是user对象：
和OrderInfo类似，我们也使用数组来存放用户所下的订单。
那么实体对象和数据表我们就都有了，下面来编写iBatis的sqlMap文件来描述它们之间的关系，我们自定义resultMap来说明：
描述OrderItem则是最简单的了，就是刻画各个属性即可。
在刻画OrderInfo时，我们加入了一个select查询，就是查到该订单下的所有订单项，并使用数组保存起来，那么上面这段XML代码就好理解了。
和上面的订单项是类似的，我们在查询用户时，也把用户所下的订单都给查出来。最后我们是要获取内系统的所有用户，那么使用下面的这个SQL：
综上的XML表述了这么一个需求，就是查询系统的内的所有用户，以及它们所下的所有订单，并还要查出每个订单项。
那么示例程序就很简单了：
运行程序，我们可以得到如下输出：
查询得到的内容为：
[UserInfo [orderList=[OrderInfo [order=Order [generateTime=Mon Aug 27 21:35:27 CST 2012, orderId=1, orderItems=null, orderName=Mobile Phone], orderItemList=[OrderItem [itemName=Moto MB525, orderItemId=1, orderId=1, price=1000.0, quantity=1], OrderItem [itemName=Moto MB526, orderItemId=2, orderId=1, price=1200.0, quantity=1]]], OrderInfo [order=Order [generateTime=Mon Aug 27 22:28:38 CST 2012, orderId=2, orderItems=null, orderName=Laptop], orderItemList=[OrderItem [itemName=Lenovo X201, orderItemId=3, orderId=2, price=5000.0, quantity=1], OrderItem [itemName=Lenovo X220, orderItemId=4, orderId=2, price=7000.0, quantity=1]]]], user=User [age=0, email=null, mobile=null, password=null, userId=1, userName=Sarin]]]
他们都是以对象的形式来描述的，因为我们命没有查询user的email，mobile等信息，所以它们是null。
程序编写完了，但是问题随之而来。先看这么一大堆的输出，我们仅仅有1个用户的两个订单，每个订单仅包含2个项。如果我们的系统内有10000个用户，每个用户下了100个订单，每个订单有5项，那么一次查询结果就会生成500万个对象，显然在数据不是很多时，就已经带来了问题。首先这是一个数据库I/O的问题，大量数据库I/O和内存对象，降低了性能，消耗了资源。其次是N+1查询问题。
N+1问题也好理解，在本例中，我们要查询一个用户的N个订单，还要查询这N个订单中每个订单的N个订单项，就产生了N+1查询问题。
iBatis提供了针对每个问题的解决方案，但是却不能同时解决这两个问题。
针对数据库I/O，我们很容易想到延迟加载的特性，就是对于所有数据并不是一次全部查出，在需要的时候继续进行查询，那么就会大幅度减少数据库的I/O，开启iBatis的延迟加载特性非常简单，只需修改如下XML设置即可：
也就是在settings中设置了lazyLoadingEnabled为true，如果想开启cglib的增强版，需要在类路径下添加相关jar包，并设置enhancementEnabled为true即可。但是要清楚一点，这些设置都是全局的设置，也就是说项目中的其它iBatis查询都将应用延迟加载特性。下面我们来测试一下代码：
可以看到，在仅有的几条数据时，所消耗的时间也大幅减少，说明延迟加载特性已经启用。
下面我们来看针对N+1查询问题的解决方案，那就是使用iBatis在resultMap中为我们提供的groupBy属性。我们将上面的XML文件修改如下：
resultMap的配置使用了groupBy属性，其余和上面配置类似，而这次我们的查询语句就合并成一个连接查询，测试时，需要修改POJO中的数组变量为单对象变量，那么执行程序后，我们得到如下效果：
也可以看到查询效率的显著提升。
综上所述，延迟加载适用于大型数据集合，但是并非其中的每条记录都会被用到。此方法前期的性能大幅度提高，但是后期仍需加载所需数据。而N+1查询解决方案适用于小型数据集合或者是所有数据都肯定会被用到的数据集合，使得整体性能得到提高。
1 楼 hellostory 2012-09-05 用mybatis3的人越来越多，如果有就更好 2 楼 SunJK000 2012-10-09 hellostory 写道用mybatis3的人越来越多，如果有就更好
支持
