可以考慮根據(jù)對(duì)象的關(guān)系（關(guān)聯(lián)）來定義數(shù)據(jù)模型，然后使用iBATIS將它們一起加載。例如，如果在數(shù)據(jù)庫中，Account記錄對(duì)應(yīng)著相關(guān)的Order記錄，而Order又對(duì)應(yīng)著相關(guān)的OrderItem記錄，可以為這些記錄建立關(guān)系，當(dāng)我們請(qǐng)求一條Account記錄時(shí)，可以一并獲取所有的Order和OrderItem記錄。下面的代碼清單顯示了如何定義我們的SQL映射：

<resultMap?id="ResultAccountInfoMap"?class="AccountInfo">
????<result?property="accountId"
????column="accountId"?/>
????<result?property="orderList"?
????select="Ch6.getOrderInfoList"
????column="accountId"?/>
</resultMap>
<resultMap?id="ResultOrderInfoMap"?class="OrderInfo">
????<result?property="orderId"?column="orderId"?/>
????<result?property="orderItemList"?column="orderId"
????select="Ch6.getOrderItemList"?/>
</resultMap>
<resultMap?id="ResultOrderItemMap"?class="OrderItem">
????<result?property="orderId"?column="orderId"?/>
????<result?property="orderItemId"?column="orderItemId"?/>
</resultMap>

<select?id="getAccountInfoList"?resultMap="ResultAccountInfoMap"?>
????select?accountId?from?Account
</select>
<select?id="getOrderInfoList"?resultMap="ResultOrderInfoMap">
????select?orderId?from?orders
????where?accountId?=?#value#
</select>
<select?id="getOrderItemList"?resultMap="ResultOrderItemMap">
????select?orderId,?orderItemId?from?orderItem
????where?orderid?=?#value#
</select>

先來看看結(jié)果映射（result map，即上面的ResultAccountInfoMap，ResultOrderInfoMap和ResultOrderItemMap），前兩個(gè)Map都用到了select特性。這個(gè)特性告訴iBATIS，屬性的值將由另一個(gè)映射語句來設(shè)置，語句的名稱就是select特性的值。例如，我們執(zhí)行getAccountInfoList語句時(shí)，ResultAccountInfoMap結(jié)果映射有一個(gè)子元素：

<resultproperty="orderList"?select="Ch6.getOrderInfoList"?column="accountId"?/>

它的作用是告訴iBATIS，account對(duì)象的orderList屬性的值由Ch6.getOrderInfoList語句來設(shè)置，同時(shí)把a(bǔ)ccountId列的值傳給Ch6.getOrderInfoList作為參數(shù)。類似地，在設(shè)置order對(duì)象的orderItemList對(duì)象時(shí)，也會(huì)執(zhí)行g(shù)etOrderItemList語句。

這個(gè)功能給我們帶來便利的同時(shí)，也帶來了兩個(gè)問題。首先，創(chuàng)建包含大量對(duì)象的列表可能會(huì)消耗大量的內(nèi)存。其次，這種方法會(huì)導(dǎo)致數(shù)據(jù)庫的I/O問題，其原因是所謂的“N+1 Select”現(xiàn)象，這個(gè)現(xiàn)象將在后面討論。對(duì)于每個(gè)問題，iBATIS框架都提供了解決方案，但是注意，沒有哪一種能同時(shí)解決這兩個(gè)問題。

數(shù)據(jù)庫I/O

數(shù)據(jù)庫I/O是數(shù)據(jù)庫使用狀況的一項(xiàng)指標(biāo)，也是數(shù)據(jù)庫性能的主要瓶頸之一。在讀取或?qū)懭霐?shù)據(jù)庫時(shí)，數(shù)據(jù)必須要經(jīng)歷從磁盤到內(nèi)存或者從內(nèi)存到磁盤的轉(zhuǎn)換，這個(gè)過程是比較耗時(shí)的。在程序中使用緩存可以減少對(duì)數(shù)據(jù)庫的訪問，但這種方法使用時(shí)要謹(jǐn)慎，否則也會(huì)引發(fā)問題。要了解iBATIS中的緩存機(jī)制，可以參看第10章的內(nèi)容。

在使用關(guān)聯(lián)數(shù)據(jù)時(shí)，可能會(huì)遭遇數(shù)據(jù)庫I/O問題。考慮一下這個(gè)場(chǎng)景：有1000個(gè)Account，每一個(gè)關(guān)聯(lián)了1000個(gè)Order，而每個(gè)Order則包含25個(gè)OrderItem。如果嘗試將所有這些數(shù)據(jù)加載到內(nèi)存，執(zhí)行的SQL語句要超過1000000行（1條用來查詢Account，1000條用于Order，1000000條用于OrderItem），而創(chuàng)建的對(duì)象大約為2500萬——如果你真敢這么做，等你的系統(tǒng)管理員收拾你吧。

分析N＋1查詢問題

N＋1查詢問題是由于試圖加載多個(gè)父記錄（比如Account）的子記錄（Order）而引起的。因此，在查詢父記錄時(shí)，只需要1條語句，假設(shè)返回N條記錄，那么就需要再執(zhí)行N條語句來查詢子記錄，引發(fā)所謂的“N＋1查詢”。

這些問題的解決方案

延遲加載（Lazy load，在6.2.2中詳細(xì)講述）可以解決一部分內(nèi)存問題，它將加載過程打散為一些更小的過程。但是，它并沒有解決數(shù)據(jù)庫I/O問題，在最壞的情況下，它對(duì)數(shù)據(jù)庫的訪問次數(shù)與非延遲加載的版本是一樣的，因?yàn)榧虞d數(shù)據(jù)時(shí)它的方法還是N＋1查詢（這個(gè)我們將在6.2.3中解決）。另一方面，當(dāng)我們解決了N＋1查詢問題，減少了對(duì)數(shù)據(jù)庫的訪問，但我們的查詢結(jié)果卻包含著2500萬行記錄！

要決定是否使用復(fù)雜屬性，我們需要理解數(shù)據(jù)庫以及應(yīng)用程序?qū)?shù)據(jù)庫的使用方式。如果您使用了本節(jié)中的技術(shù)，那可以省不少事兒，但如果誤用了它，也會(huì)有大麻煩。在接下來的兩節(jié)中，我們會(huì)分析如何根據(jù)目標(biāo)選擇合適的策略。

讓我們從這個(gè)問題開始：像上面例子那樣將Account關(guān)聯(lián)到Order并將Order關(guān)聯(lián)到OrderItem是否合適？實(shí)際上，不是——order-to-orderitem關(guān)系是固定的，但是account-to-order關(guān)系則是不必要的。

我們是如是推理的：沒有所屬的Order，OrderItem是沒有意義的，而Account則是有意義的。一般情況下，沒有OrderItem，Order沒什么大用，相對(duì)的，不屬于任何Order的OrderItem是沒有意義的。另一方面，一個(gè)Account則可以認(rèn)為是一個(gè)完整的對(duì)象。

但在我們的例子中，這種關(guān)系可以良好地描述相關(guān)的技術(shù)，因此我們會(huì)在一段時(shí)間內(nèi)一直使用它。

6.2.2?延遲加載（Lazy loading）

首先來看看延遲加載。如果不是對(duì)所有數(shù)據(jù)都馬上用到，那么延遲加載是有用的。例如，我們的程序首先在一個(gè)網(wǎng)頁顯示所有Account，然后銷售代理（我們的客戶）可以點(diǎn)擊一個(gè)Account來查看該Account的Order列表，然后可以再點(diǎn)擊一個(gè)Order來查看其所有的OrderItem信息。在這種情況下，每次都僅查詢一個(gè)列表。這是對(duì)延遲加載的合理使用。

譯注：在iBATIS的Java版本中，使用延遲加載前還需要進(jìn)行配置SqlMapConfig.xml以打開該功能。在.NET版本中不需要配置等價(jià)的sqlMap.config。

使用了延遲加載后，我們就可以更合理地進(jìn)行對(duì)象創(chuàng)建和對(duì)數(shù)據(jù)庫的訪問。（還是使用上面的例子）如果一個(gè)用戶關(guān)注到OrderItem層次的數(shù)據(jù)，我們需要進(jìn)行三次查詢（一次是為Account，一次是Order，還有一次是OrderItem），應(yīng)用程序則要?jiǎng)?chuàng)建2025個(gè)對(duì)象（1000個(gè)Account，?1000個(gè)Order，25個(gè)OrderItem）。效果明顯！而我們要做的僅僅是修改XML配置文件的一個(gè)特性（attribute）而已，無需改動(dòng)代碼。

在一項(xiàng)不太嚴(yán)謹(jǐn)?shù)臏y(cè)試中，我們發(fā)現(xiàn)，對(duì)于同樣的對(duì)象關(guān)聯(lián)關(guān)系（如上面的Account- Order- ORderItem），在加載第一個(gè)列表數(shù)據(jù)時(shí)（Account列表），沒有使用延遲加載的版本花費(fèi)的時(shí)間是使用了延遲加載的版本的三倍。但是，在加載所有數(shù)據(jù)時(shí)，延遲加載的版本的時(shí)間卻多了20％。很明顯，我們要根據(jù)數(shù)據(jù)加載的數(shù)量和時(shí)機(jī)來確定是否采用延遲加載。此時(shí)，經(jīng)驗(yàn)是最重要的。

而有時(shí)您并不希望推遲數(shù)據(jù)的加載，而是希望在第一次請(qǐng)求的時(shí)候加載所有的數(shù)據(jù)。在這種情況下，您可以使用下節(jié)中的技術(shù)，它僅需要一次查詢即可。下節(jié)的方法避免了“N＋1查詢”。

6.2.3?避免“N＋1查詢”問題

我們來考慮如何避免“N＋1查詢”問題，這里可以使用連接語句（Join）。

這里用到的技術(shù)同前面類似。簡(jiǎn)單的說，使用Result Map來定義對(duì)象間的關(guān)系，將頂層的Result Map關(guān)聯(lián)到映射語句。下面的例子的Data Map文件結(jié)構(gòu)與前面大體一致，但是只需要執(zhí)行一條SQL語句。

這里面有三個(gè)Result Map，一是關(guān)于Account的，二是關(guān)于Order的，三是OrderItem的。

關(guān)于Account的Result Map有兩個(gè)作用：

• ?映射Account對(duì)象本身的屬性。
• 告訴iBATIS如何映射下一層的關(guān)聯(lián)對(duì)象，這里是orderList。

Order的Result Map作用與之類似。

• 映射Order對(duì)象本身的屬性。
• 告訴iBATIS如何映射下一層的關(guān)聯(lián)對(duì)象，這里是orderItemList。

<resultMap?id="ResultAccountInfoNMap"?class="AccountInfo">
????<result?property="account.accountId"?column="accountId"?/>
????<result?property="orderList"?resultMapping="Ch6.ResultOrderInfoNMap"?/>
</resultMap>
<resultMap?id="ResultOrderInfoNMap"?class="OrderInfo">
????<result?property="order.orderId"?column="orderId"?/>
????<result?property="orderItemList"?resultMapping="Ch6.ResultOrderItemNMap"?/>
</resultMap>
<resultMap?id="ResultOrderItemNMap"?class="OrderItem">
????<result?property="orderId"?column="orderId"?/>
????<result?property="orderItemId"?column="orderItemId"?/>
</resultMap>

<select?id="getAccountInfoListN"?resultMap="ResultAccountInfoNMap">
????select?account.accountId?as?accountid,
????orders.orderid?as?orderid,
????orderitem.orderitemid?as?orderitemid
????from?account
????inner?join?orders?on?account.accountId?=?orders.accountId
????inner?join?orderitem?on?orders.orderId?=?orderitem.orderId
????order?by?accountId,?orderid,?orderitemid
</select>
我們的不太科學(xué)的測(cè)試表明，在加載少量數(shù)據(jù)時(shí)，該方法將原先方法的性能提高為7：1。我們猜想，對(duì)于例子中使用的2500萬條數(shù)據(jù)，兩種方法仍然不錯(cuò)。

譯注：在iBATIS.NET DataMapper 1.6.1中，添加了groupBy特性，它將進(jìn)一步改善性能。詳細(xì)內(nèi)容請(qǐng)參看相關(guān)文檔，本文使用的是DataMapper 1.5.1。

需要注意的是，盡管性能得到改善，內(nèi)存的消耗仍然與沒有使用延遲加載的版本相同。所有的記錄一起放入內(nèi)存，因此盡管它稍微快了一點(diǎn)，但內(nèi)存的消耗仍是問題。

譯注：在加載復(fù)雜屬性時(shí)可能出現(xiàn)兩方面的問題，一是對(duì)數(shù)據(jù)庫的訪問，二是創(chuàng)建對(duì)象時(shí)對(duì)內(nèi)存的消耗。我們可以采用延遲加載或Join的方法來解決這些問題，但是兩者都不是萬靈藥。延遲加載的原理時(shí)推遲對(duì)復(fù)雜屬性的加載，以減少對(duì)數(shù)據(jù)庫的訪問和對(duì)象的創(chuàng)建，但它的前提是復(fù)雜屬性不會(huì)馬上用到，否則的話，延遲就失去意義。Join的原理是通過一條SQL語句加載所有數(shù)據(jù)，這樣可以大幅度減少對(duì)數(shù)據(jù)庫的訪問量，它的前提是對(duì)象的數(shù)量不會(huì)太多。該如何選擇呢？下面的表格給出了簡(jiǎn)單的原則：

延遲加載	Join
如果要加載大量的數(shù)據(jù)，它們不會(huì)馬上用到，延遲加載會(huì)比較合適。	數(shù)據(jù)量較小或者數(shù)據(jù)馬上就會(huì)用到，Join方法比較合適。

譯注：另外，我覺得還有一條很重要的原則，那就是永遠(yuǎn)只加載必需的數(shù)據(jù)。以上面的例子來說，我們不太可能會(huì)同時(shí)顯示1000個(gè)Account給用戶看，這時(shí)就不要同時(shí)加載1000個(gè)Account的數(shù)據(jù)了，可以通過分頁只顯示50條數(shù)據(jù)，在此基礎(chǔ)上再應(yīng)用延遲加載或Join效果會(huì)很不錯(cuò)。關(guān)于在Web項(xiàng)目中如何使用iBATIS進(jìn)行分頁，請(qǐng)參看這篇文章。

好了，這些就是復(fù)雜屬性映射相關(guān)的內(nèi)容。下一篇中，我們將會(huì)了解iBATIS的其它用法。

上一篇：iBATIS In Action：執(zhí)行非查詢語句（二）；

下一篇：iBATIS In Action：使用高級(jí)查詢技術(shù)（二）；

本文轉(zhuǎn)自一個(gè)程序員的自省博客園博客，原文鏈接:http://www.cnblogs.com/anderslly/archive/2007/12/27/ibatisinactionch062.html，如需轉(zhuǎn)載請(qǐng)自行聯(lián)系原作者。

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的iBATIS In Action：使用高级查询技术（一）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。