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