一：
像 Hibernate 和 OJB 之類的對(duì)象映射工具都非常風(fēng)行——并且應(yīng)當(dāng)如此。這些工具將 JDBC 從 JDBC 程序設(shè)計(jì)中分離出來(lái)，從而使得編寫(xiě)數(shù)據(jù)庫(kù)訪問(wèn)代碼如同處理文件 I/O 一樣簡(jiǎn)單。
|
<![CDATA[<a target="_top"></a> ]]> |
最近一個(gè)有影響力的對(duì)象映射工具是iBATIS-Database Layer。iBATIS 不同于其它對(duì)象映射工具的地方在于它不是將對(duì)象映射到數(shù)據(jù)庫(kù)，而是將 SQL 映射為對(duì)象，反之將對(duì)象映射為 SQL。簡(jiǎn)單的映射基礎(chǔ)使得具有 Java 和 SQL 經(jīng)驗(yàn)的開(kāi)發(fā)人員很容易開(kāi)始使用 iBATIS。
iBATIS-Database Layer 的核心是 XML 文件，例如：
<mapped-statement name="loadEmployee" result-class="tips.Employee">
select
emp_id as id,
last_name as lastName,
first_name as firstName,
title as title,
from employees
where emp_id = #value#
</mapped-statement>
創(chuàng)建一個(gè) Employee 對(duì)象的動(dòng)作直接映射到一個(gè) SQL 語(yǔ)句。
創(chuàng)建能夠執(zhí)行 SQL 的對(duì)象的方式如下：
public Employee getEmployeeById(Long id) {
Employee employee = (Employee) sqlMap.executeQueryForObject("loadEmployee",
id);
}
iBATIS-Database Layer 支持對(duì)各種手工數(shù)據(jù)庫(kù)操作動(dòng)作的映射：插入、更新及刪除。它還具有其它對(duì)象映射工具的優(yōu)點(diǎn)，比如說(shuō)多數(shù)據(jù)庫(kù)支持、數(shù)據(jù)源配置、將依賴對(duì)象映射為屬性等等。使用 iBATIS 的另一個(gè)優(yōu)點(diǎn)是其學(xué)習(xí)曲線比較溫和，因?yàn)槟阋呀?jīng)了解了SQL，這就相當(dāng)于了解了 iBATIS 的一半。然而，有其好處的同時(shí)也會(huì)有其（最起碼是警告級(jí)的）壞處。
因?yàn)槟闶亲约壕帉?xiě) SQL，所以你可能會(huì)在 SQL 中使用針對(duì)某個(gè)特定數(shù)據(jù)庫(kù)的優(yōu)化技術(shù)。使用針對(duì)特定數(shù)據(jù)庫(kù)的 SQL 意味著如果你決定更換數(shù)據(jù)庫(kù)那么你就必須移值你的映射。
即使有這種警告，iBATIS-Database Layer 依然值得考慮。自己衡量一下，看看這個(gè)框架對(duì)你是否有所幫助。
二：
EJB很重，不需要分布式的中小項(xiàng)目慎用，Hibernate雖好，公司缺少高水平的OO設(shè)計(jì)師，程序員水平參次不齊，iBatis是我本人比較喜好的半自動(dòng)ORM東東。
持久層使用了iBatis后，團(tuán)隊(duì)中以前八仙過(guò)海的jdbc包裝不見(jiàn)了，大家的編碼風(fēng)格統(tǒng)一了，會(huì)補(bǔ)長(zhǎng)木桶較短的木板。大家不會(huì)再把精力浪費(fèi)到分頁(yè) 連接池 主鍵生成等地方了,可以集中精力進(jìn)行業(yè)務(wù)組件的編寫(xiě)。
以下是個(gè)人感受：
1.緩存不用太可惜，不過(guò)具體用哪一種(MEMORY LUR FIFO OSCACHE)容量設(shè)多大，都得根據(jù)項(xiàng)目的實(shí)際情況來(lái)定，我通常首選LUR。正確設(shè)定緩存的Flush語(yǔ)句，杜絕緩存中臟數(shù)據(jù)產(chǎn)生的可能。緩存使用前提是，系統(tǒng)中對(duì)表的讀寫(xiě)一定要都通過(guò)ibatis來(lái)進(jìn)行，也就是封閉的。
2.動(dòng)態(tài)SQL的確是個(gè)強(qiáng)點(diǎn)。熟悉后感覺(jué)很不錯(cuò)。iBatis中所有的DAO方法都只傳一個(gè)值對(duì)象，復(fù)雜查詢當(dāng)然也不例外。
3.復(fù)雜對(duì)象一定要lazyload = true. 對(duì)于性能上有一定的好處。
4.iBatis其實(shí)已經(jīng)把Dao接口和SQLMap實(shí)現(xiàn)層實(shí)現(xiàn)了解藕，感覺(jué)有點(diǎn)象Spring倡導(dǎo)的Ioc.
5.通常我會(huì)在寫(xiě)完Service接口后，直接寫(xiě)一個(gè)junit測(cè)試類，它是業(yè)務(wù)層和WEB層的連接點(diǎn)，進(jìn)行測(cè)試很重要，一是方便重構(gòu)后檢測(cè)是否破壞了功能，另外，編寫(xiě)測(cè)試類也是一個(gè)掌握此類用法的過(guò)程。看著一排綠色的通過(guò)進(jìn)度條，心情大好。
6.關(guān)于輔助工具：hibernate帶的工具就很方便，iBatis的開(kāi)發(fā)者好象覺(jué)得這個(gè)夠簡(jiǎn)單了，沒(méi)必要弄這么個(gè)工具。現(xiàn)在其官方網(wǎng)站的主頁(yè)上有一個(gè)用Perl寫(xiě)的生成器，用表的DLL腳本作為源，自動(dòng)化產(chǎn)生Pojo 和sqlMap xml配置文件，我down下來(lái)測(cè)試了一下，郁悶，60％都會(huì)報(bào)錯(cuò)，不知為何。我考慮用Java或delphi寫(xiě)一個(gè)簡(jiǎn)單易用的，有GUI的。如果有達(dá)人知道網(wǎng)上哪兒有了這么個(gè)東西，請(qǐng)告訴我，非常感謝。
三：關(guān)于iBatis的緩存使用
在你的xml配置文件中，每一個(gè) cacheModel 元素，如下
<cacheModel id="oneday_cache" type="LRU" readOnly="false" serialize="true">
<flushInterval hours="24"/>
<flushOnExecute statement="updateMyDate"/>
<property name="size" value="200"/>
</cacheModel>
1 屬性readOnly如果不寫(xiě)，默認(rèn)是true,這時(shí)的緩存效果無(wú)疑最好，因?yàn)橄到y(tǒng)不需要考慮更新操作引起緩存與實(shí)際數(shù)據(jù)不一致的問(wèn)題，只讀緩存的例子是固化到數(shù)據(jù)庫(kù)中的一些配置參數(shù)表。但是，通常我們想緩存的數(shù)據(jù)是需要增刪改的，這時(shí)務(wù)必記得要加上 readOnly = "false"；
2 屬性serialize,如果不寫(xiě)，默認(rèn)為false, 將它設(shè)為true,可以提高整體應(yīng)用（而不僅僅是每個(gè)Session）的性能。 這種緩存為每一個(gè)Session返回緩存對(duì)象不同的實(shí)例（復(fù)本）。因此每一個(gè)Session都可以安全修改返回的對(duì)象. 注意，此時(shí)readOnly必須為false。
如果你把它設(shè)為 true ,記得檢查兩件事，一件事是緩存中存放的對(duì)象(你想查詢的POJO)必須是可序列化的， 即實(shí)現(xiàn)Serializable接口。如果你有一個(gè)復(fù)雜對(duì)象屬性，它也必須滿足這個(gè)規(guī)則，你的整個(gè)對(duì)象樹(shù)必須是可序列化的。
另一件事是關(guān)閉sql-map-config中的延遲加載屬性，即lazyload=false,原因是，它使用了動(dòng)態(tài)代理機(jī)制， 那個(gè)代理對(duì)象并不是Serializable的。
緩存類型的最佳適應(yīng)情形：
MEMORY 沒(méi)有統(tǒng)一的對(duì)象重用模式的應(yīng)用，或內(nèi)存不足的應(yīng)用。
LRU 在較長(zhǎng)的期間內(nèi)，用戶經(jīng)常使用某些特定對(duì)象。
FIFO 用戶在短時(shí)間內(nèi)持續(xù)引用特定的查詢，而后很可能不再使用。
根據(jù)個(gè)人實(shí)踐，內(nèi)存充足時(shí)使用LRU，否則使用MEMORY(WEAK)通常能獲得較好的效果。