Hibernate ibatis全面概括
使用ibatis需要自己寫SQL時，由于我們的SQL不可能完全符合SQL標準，比起Hibernate產生的SQL來，可移植性差。不過由于我們更改 數據庫的可能性較小，對我們來說SQL符合標準以便可以在遷移到不同服務器時代價最小并不是十分必要的。另一方面，Hibernate雖然可以屏蔽很多 數據庫間的不同，但是卻很難利用某些數據庫的高級特性，比如oracle的分析統計函數。
Hibernate不適合數據庫模式不規范，約束不完整，需要大量復雜查詢的系統，同時Hibernate的學習成本較高，完全掌握Hibernate也較困難，風險較大。
自己寫框架未必比ibatis的好，穩定，強大和可擴展。而且自己開發框架也需要較大的工作量。
如果使用dotnet并且要選一個數據層框架，而系統中有相當一部分較復雜的SQL，或數據庫設計不合理，臟數據多，對性能和資源要求嚴格，ibatis 是一個比較不錯的選擇。他的那些缺點并不是致命的，而且也是有一些解決方案的。尤其是，當選用了ibatis的dataaccess作為dao框架時，我們可以同時使用Hibernate，ado.net和datamapper（ibatisnet的核心組件），那樣將會使風險降到***，并且整個系統的 框架比較合理。
另外，利用ibatis可以統一編碼風格，節約開發成本，大家不會再把精力浪費到分頁 連接池 主鍵生成等地方了，可以集中精力進行業務組件的編寫。
綜上： 很多時候我們要在是自己開發框架和選用第三方框架和選用什么樣的框架問題上進行綜合考慮。考慮的標準當然是項目的當前情況和我們希望達到目的的一個平衡。
ibatis只是封裝了數據訪問層，替我們做了部分的對象關系映射。但我們的代價是必須要寫xml配置文件，相對于Hibernate我們還要寫很多 SQL.Hibernate通過工具直接從數據庫模式生成實體類和基本的配置文件，而且大部分情況下不需要我們寫SQL，會較大的提升開發效率。但這些也 有很多的局限性，尤其是對環境的要求較高（數據庫設計，對象設計，團隊的協作等）。
個人感覺ibatis對項目比較有意義的地方在于它小巧靈活，可擴展，封裝了數據訪問層（事務，緩存，異常，日志），并提供了dao框架支持。
利用ibatis我們可以做到代碼和SQL的分離，只要SQL能夠解決的問題，ibatis就能幫我們較容易的解決，同時也使我們的項目對某一框架的依賴性變小（因為ibatis是非侵入性的）。這將極大的降低項目風險，減少解決復雜問題的時間，使項目的維護變得簡單。
ibatis對于應用的修改，調試，擴充和維護將會變得容易自然。修改時，我們主要修改的是代表模型的實體對象，xml配置文件中的SQL，和/或配置文件的resultmap（很多時候是不需要的）。同時，SQL和代碼分離，我們不用在代碼的stringbuffer的append方法之間尋找需要修改的SQL.配置文件中的SQL便利了我們的調試和對SQL的評審及以后的SQL重用。
利用一些框架在前期一般會拖慢開發效率。因為我們需要付出學習成本，很多時候，使用框架需要寫很多配置文件，在使用不熟時開發速度較慢；同時利用框架往往使系統代碼量增大，比如model1和model2模型，開發效率應該還是model1快，四層的架構肯定比兩層的代碼量大。但對于中后期開發和維護將會極大的提高效率。
利用一些較完全的開發框架和代碼生成工具，在前期會較大的提高開發效率，但在后期常常會拖慢進度，并有可能成為以后維護的夢魘。比如torque生成實體類和其對應的SQL，雖大幅提高了效率，但修改負擔較大。
比較理想的開發方式是使用簡單框架結合簡單的代碼生成工具。框架提供系統的基礎服務，并規范開發。框架一方面提供了開發中某一方面的開發基礎支持，比如數據訪問層，事務，日志，公用類，異常等。另一方面，也為開發定義了模式，定義了系統的基本輪廓。同時，通過簡單的代碼生成工具生成部分低級的代碼。比如通過工具從數據庫模式生成實體類。這些類生成后我們可以自由修改。
Hibernate是十分強大，比較完善的orm框架，不過這是它的優點也是它的缺點。 J2EE系統是否采用Hibernate3，是一個需要認真評估的問題。
要想Hibernate工作的好，數據庫的設計必須好。同時對于復雜的數據操作同時需要使用SQL，Hibernate3對于直接使用SQL的支持比Hibernate2要自然，這一點是可以接受的。
Hibernate比較復雜，功能強大而靈活，要用好Hibernate確實不是很簡單，當然spring框架提供了對Hibernate的封裝，使Hibernate的使用變得簡單了點。
可以說ibatis在任何系統里都適用，但未必是***選擇。不過ibatis提供的思路是我們應該仔細考慮的。
【編輯推薦】
