iBatis和Hibernate的5點區別及選擇要素
我在最初的選型的時候，考慮到iBatis和Hibernate不同，本來打算選擇Hibernate的，在研究的過程中發現了iBatis的特性，經過分析比較之后我選擇了iBatis。現在我已經使用iBatis 完成了一個中小型的項目。這個項目在性能、可維護性、可擴展性方面都非常令我滿意。
在這個過程中我也不斷的與使用過或者正在使用Hibernate的人進行過探討。而且我本身也在不斷的跟進Hibernate的發展。
最終，我的結論是iBatis的選擇非常正確，而且越用越喜歡它了。
當然了，我對iBatis和Hibernate的理解還是非常有限的，所以這里的關于Hibernate的一些觀點的錯誤之處希望能夠得到Hibernate高手的指正。
1. iBatis的特性易于掌握
iBatis的特性拿來文檔看半天到兩天就可以掌握了。Hibernate可能需要3倍以上的時間來掌握。
2.iBatis的特性更容易進行SQL的優化
這個應該大家都有共識了。另外Hibernate生成的SQL也實在是太難看了。鑒于有的朋友提到了SQL不太重要。我想在這里強調一下我的經驗，一般系統性能的瓶頸都在數據庫上。所以這一點是iBatis和Hibernate比較后非常重要的一個優勢。
3.iBatis的特性是可以進行細粒度的優化
3.1 比如說我有一個表，這個表有幾個或者幾十個字段，我需要更新其中的一個字段，iBatis 很簡單，執行一個SQLUPDATE TABLE_A SET column_1=#column_1# WHERE id=#id# 但是用Hibernate的話就比較麻煩了,缺省的情況下Hibernate會更新所有字段。當然我記得Hibernate有一個選項可以控制只保存修改過的字段，但是我不太確定這個功能的負面效果，因此iBatis和Hibernate比較，iBatis的優勢很明顯。
3.2 我需要列出一個表的部分內容，用iBatis的時候，這里面的好處是可以少從數據庫讀很多數據，節省流量SELECT ID, NAME FROM TABLE_WITH_A_LOT_OF_COLUMN WHERE
3.2.1 一般情況下Hibernate會把所有的字段都選出來。比如說有一個上面表有8個字段，其中有一兩個比較大的字段，varchar(255)/text。上面的場景中我為什么要把他們也選出來呢？
3.2.2 用Hibernate的話，你又不能把這兩個不需要的字段設置為 lazy load，因為還有很多地方需要一次把整個 domain object 加載出來。這個時候就能顯現出iBatis的好處了。
3.2.3Hibernate還有一個方案，就是生成 javabean/map/object[](感謝 leelun/cjmm)，但是這樣的話就可能會產生大量的多余 class。map/object[] 的方式應該不錯，我比較喜歡這種方式。
3.3 如果我需要更新一條記錄（一個對象），如果使用Hibernate，需要現把對象 select 出來，然后再做 update。這對數據庫來說就是兩條SQL。而iBatis只需要一條 update 的SQL就可以了。減少一次與數據庫的交互，對于性能的提升是非常重要。
4. 開發方面
4.1 開發效率上，我覺得iBatis和Hibernate應該差不多
4.2 可維護性方面，我覺得iBatis更好一些。因為iBatis的 SQL都保存到單獨的文件中。而Hibernate在有些情況下可能會在 java 代碼中保存sql/hql。
5. 運行效率
5.1 在不考慮 cache 的情況下，iBatis 應該會比Hibernate快一些或者很多（根據實際情況會有所不同）。
當然 iBatis和Hibernate相比也有比較大的缺點
1. 不同數據庫類型的支持不好，如果你要開發的系統是要在對中數據間移植，那可能用Hibernate比較好。
2. 缺省的 cache 支持不好，但是Hibernate的 cache 支持其實也不是很好，而且很復雜。尤其是對于大并發量的應用。所以我更傾向于自己管理 cache。
【編輯推薦】
