海鷗航際

一：

像 Hibernate 和 OJB 之類的對象映射工具都非常風(fēng)行——并且應(yīng)當(dāng)如此。這些工具將 JDBC 從 JDBC 程序設(shè)計(jì)中分離出來，從而使得編寫數(shù)據(jù)庫訪問代碼如同處理文件 I/O 一樣簡單。

最近一個(gè)有影響力的對象映射工具是iBATIS-Database Layer。iBATIS 不同于其它對象映射工具的地方在于它不是將對象映射到數(shù)據(jù)庫，而是將 SQL 映射為對象，反之將對象映射為 SQL。簡單的映射基礎(chǔ)使得具有 Java 和 SQL 經(jīng)驗(yàn)的開發(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)建一個(gè) Employee 對象的動(dòng)作直接映射到一個(gè) SQL 語句。

創(chuàng)建能夠執(zhí)行 SQL 的對象的方式如下：

public Employee getEmployeeById(Long id) {
    Employee employee = (Employee) sqlMap.executeQueryForObject("loadEmployee",
 id);
}

iBATIS-Database Layer 支持對各種手工數(shù)據(jù)庫操作動(dòng)作的映射：插入、更新及刪除。它還具有其它對象映射工具的優(yōu)點(diǎn)，比如說多數(shù)據(jù)庫支持、數(shù)據(jù)源配置、將依賴對象映射為屬性等等。使用 iBATIS 的另一個(gè)優(yōu)點(diǎn)是其學(xué)習(xí)曲線比較溫和，因?yàn)槟阋呀?jīng)了解了SQL，這就相當(dāng)于了解了 iBATIS 的一半。然而，有其好處的同時(shí)也會有其（最起碼是警告級的）壞處。

因?yàn)槟闶亲约壕帉?SQL，所以你可能會在 SQL 中使用針對某個(gè)特定數(shù)據(jù)庫的優(yōu)化技術(shù)。使用針對特定數(shù)據(jù)庫的 SQL 意味著如果你決定更換數(shù)據(jù)庫那么你就必須移值你的映射。

即使有這種警告，iBATIS-Database Layer 依然值得考慮。自己衡量一下，看看這個(gè)框架對你是否有所幫助。

二：

EJB很重，不需要分布式的中小項(xiàng)目慎用，Hibernate雖好，公司缺少高水平的OO設(shè)計(jì)師，程序員水平參次不齊，iBatis是我本人比較喜好的半自動(dòng)ORM東東。
持久層使用了iBatis后，團(tuán)隊(duì)中以前八仙過海的jdbc包裝不見了，大家的編碼風(fēng)格統(tǒng)一了，會補(bǔ)長木桶較短的木板。大家不會再把精力浪費(fèi)到分頁  連接池 主鍵生成等地方了,可以集中精力進(jìn)行業(yè)務(wù)組件的編寫。  
       以下是個(gè)人感受： 
       1.緩存不用太可惜，不過具體用哪一種(MEMORY  LUR  FIFO  OSCACHE)容量設(shè)多大，都得根據(jù)項(xiàng)目的實(shí)際情況來定，我通常首選LUR。正確設(shè)定緩存的Flush語句，杜絕緩存中臟數(shù)據(jù)產(chǎn)生的可能。緩存使用前提是，系統(tǒng)中對表的讀寫一定要都通過ibatis來進(jìn)行，也就是封閉的。  
       2.動(dòng)態(tài)SQL的確是個(gè)強(qiáng)點(diǎn)。熟悉后感覺很不錯(cuò)。iBatis中所有的DAO方法都只傳一個(gè)值對象，復(fù)雜查詢當(dāng)然也不例外。  
       3.復(fù)雜對象一定要lazyload  =  true.  對于性能上有一定的好處。  
       4.iBatis其實(shí)已經(jīng)把Dao接口和SQLMap實(shí)現(xiàn)層實(shí)現(xiàn)了解藕，感覺有點(diǎn)象Spring倡導(dǎo)的Ioc.  
       5.通常我會在寫完Service接口后，直接寫一個(gè)junit測試類，它是業(yè)務(wù)層和WEB層的連接點(diǎn)，進(jìn)行測試很重要，一是方便重構(gòu)后檢測是否破壞了功能，另外，編寫測試類也是一個(gè)掌握此類用法的過程。看著一排綠色的通過進(jìn)度條，心情大好。  
       6.關(guān)于輔助工具：hibernate帶的工具就很方便，iBatis的開發(fā)者好象覺得這個(gè)夠簡單了，沒必要弄這么個(gè)工具。現(xiàn)在其官方網(wǎng)站的主頁上有一個(gè)用Perl寫的生成器，用表的DLL腳本作為源，自動(dòng)化產(chǎn)生Pojo 和sqlMap xml配置文件，我down下來測試了一下，郁悶，60％都會報(bào)錯(cuò)，不知為何。我考慮用Java或delphi寫一個(gè)簡單易用的，有GUI的。如果有達(dá)人知道網(wǎng)上哪兒有了這么個(gè)東西，請告訴我，非常感謝。

三：關(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如果不寫，默認(rèn)是true,這時(shí)的緩存效果無疑最好，因?yàn)橄到y(tǒng)不需要考慮更新操作引起緩存與實(shí)際數(shù)據(jù)不一致的問題，只讀緩存的例子是固化到數(shù)據(jù)庫中的一些配置參數(shù)表。但是，通常我們想緩存的數(shù)據(jù)是需要增刪改的，這時(shí)務(wù)必記得要加上     readOnly = "false"；
 2 屬性serialize,如果不寫，默認(rèn)為false, 將它設(shè)為true,可以提高整體應(yīng)用（而不僅僅是每個(gè)Session）的性能。 這種緩存為每一個(gè)Session返回緩存對象不同的實(shí)例（復(fù)本）。因此每一個(gè)Session都可以安全修改返回的對象.   注意，此時(shí)readOnly必須為false。
     如果你把它設(shè)為 true ,記得檢查兩件事，一件事是緩存中存放的對象(你想查詢的POJO)必須是可序列化的， 即實(shí)現(xiàn)Serializable接口。如果你有一個(gè)復(fù)雜對象屬性，它也必須滿足這個(gè)規(guī)則，你的整個(gè)對象樹必須是可序列化的。
     另一件事是關(guān)閉sql-map-config中的延遲加載屬性，即lazyload=false,原因是，它使用了動(dòng)態(tài)代理機(jī)制， 那個(gè)代理對象并不是Serializable的。
  
   緩存類型的最佳適應(yīng)情形：

   MEMORY    沒有統(tǒng)一的對象重用模式的應(yīng)用，或內(nèi)存不足的應(yīng)用。
   LRU       在較長的期間內(nèi)，用戶經(jīng)常使用某些特定對象。
   FIFO      用戶在短時(shí)間內(nèi)持續(xù)引用特定的查詢，而后很可能不再使用。
  
   根據(jù)個(gè)人實(shí)踐，內(nèi)存充足時(shí)使用LRU，否則使用MEMORY(WEAK)通常能獲得較好的效果。