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