今天之天下，Hibernate橫行其道，程序員們見其霸道無比，紛紛投靠。場面是壯烈恢宏。Hibernate流行有它的道理，純粹的面向對象思想給你提供了從POJO到關系數據庫的完全映射，從此對一切對數據庫的操作都變成了簡單的幾個方法。世界好像從此清靜了。映射這方面Hibernate是功成名就，是自豪的。Ibatis更是被Hibernate遠遠拋在后面。用力點
在Hibernate這里，好像一切都成了對象，這多好，程序員可以更好的發揮對象，更好應用面向對象的思想。其不知面向對象也有它自己的缺點。所以Hibernate這把左輪手槍也會有沒有子彈的時候。
1． 系統的部分或全部數據來自現有數據庫，處于安全考慮，只對開發團隊提供幾條Select SQL（或存儲過程）以獲取所需數據，具體的表結構不予公開。
2． 開發規范中要求，所有牽涉到業務邏輯部分的數據庫操作，必須在數據庫層由存儲過程實現
3． 系統數據處理量巨大，性能要求極為苛刻，這往往意味著我們必須通過經過高度優化的SQL語句（或存儲過程）才能達到系統性能設計指標。
總上所述，Hibernate之所以會沒有子彈是因為數據庫的要求出了問題，數據庫不公開，要求盡可能的利用存儲過程，數據量大，苛刻的性能要求等等都是因為數據庫。由此可見Hibernate在封裝對象的同時也犧牲了SQL的靈活性。這時Ibatis這匹剛吃完草的馬兒是整裝上陣，蓄意待發！以上問題被Ibatis拉的遠遠的，通通解決。Ibatis在SQL上的靈活性是眾所周知。 Hibernate和Ibatis的用力點不一樣，前者盡最大努力封裝SQL，后盡最大努力靈活SQL。
易用性
iBatis 易于掌握。拿來文檔看半天到兩天就可以掌握了。Hibernate 可能需要 3 倍以上的時間來掌握。豈止是3倍，Hibernate的O/R設計及緩存機制的合理應用可不是輕易能上手的，是要靠不斷應用經驗才能熬的出來。所以不弄幾個項目出來真不敢說會用Hibernate。
性能
這可能是大家最想知道的，也是大家經常辯論的。Hibernate用HQL+緩存機制+延遲加載真能比的上直接寫的SQL。遇見大數據量情況時Hibernate的優化方案還能拿的起，放的下嗎？答案好像從來沒有確定過。因為這牽涉到很的問題，數據庫的表設計，Hibernate的緩存設計等等。Hibernate和Ibatis性能沒有高低關鍵在于設計。
存在就有它存在的道理，Hibernate和Ibatis都存在，但并一定是為我們的項目而存在，要選擇誰還要靠實際情況！