說說我們的選擇吧
原因有：
1. 我們是做平臺的，客戶要求多種多樣，我們是需要支援多個數據庫的，Hibernate可以比較容易遮蔽資料庫的差異；
2. Hibernate採用面向物件的方式來寫SQL，也就是HQL和Criteria,在資料庫和Dao之間多了一層，資料庫的改動可以透過對映關係遮蔽部分影響。
3. 因為我們是要不斷的增加功能，偶然要做做系統重構，快速快發尤其重要，Hibernate的程式碼量和改動量都要比其他框架來的少，起碼經過我們的封裝已經使得用起來是很簡單了。
4. 對於效能有影響的地方和很難用Hibernate表達的地方我們會採用JdbcTemplate，或者採用View封裝一次再map到Hibernate，採用Hibernate也不排斥其他持久層框架的存在。
5. 儘量少用One to many, Many to one等功能，可能這裡不太OO，但是程式碼明瞭,不容易出問題。
6. 我們暫時還沒有遇到幾千萬的資料量那麼大的客戶，要做到那麼大資料量的時候也可以從資料庫，系統，網路各個方面來最佳化。系統推到重來也不是什麼問題。
7.Hibernate的一級快取對於長Transaction的業務複雜的程式碼反而有好處，見上面的某些分析。
8. 採用快取和靜態頁面可以消除部分效能影響，或者採用資料庫特有功能，不過取消Hibernate的二級快取，採用Spring的快取或者自己搞快取。
9. 文件多，容易解決問題，也是JPA標準的重要參考。
Hibernate不好的地方：
1. 多佔記憶體，因為他需要把domain對應的configuration都load到記憶體裡面去，多用記憶體是正常的，但是出現OutofMemerey肯定不是Hibernate的問題了，一般應用記憶體還是夠的。
2. 效能問題。Hibernate或者Ibatis也好，最終都是透過反射把ResultSet變為對應的Domain Object,跟了一下Hibernate的內部程式碼，好像是用Method.invoke來呼叫get 和set方法的，用了Cglib或者動態代理方式，這個方式肯定是要比直接呼叫get和set方法要慢的。在JDK不斷最佳化的今天，這個差距應該會縮小。 但是Ibatais應該也是透過這個方式來做，沒有看過不太肯定。Hibernate多了一個將HQL或者Domain Object轉化為SQL的過程，這個過程也會消耗一些效能，例如字串拼接，記錄Domain Object的關係等。
經過以上分析，可能Hibernate會給我帶來一定的效能損失，但是我可以透過其他辦法來彌補，記憶體就更不是問題了。但是他確實帶來了比較好的地方，因此我們會繼續用Hibernate。
所以說Hibernate適合做企業級應用，對於那種記憶體和效能要求都很高或者本來就用Ibatis的情況，其實可以選擇Ibatias或者JdbcTemplate的。就效能而言，
JdbcTemplate > Ibatis
除了快取的作用外只說DB操作，純JDBC是最快的，因為那樣沒有任何負擔，但是程式碼搞得很難看，你會這麼選擇嗎？
說說我們的選擇吧
原因有：
1. 我們是做平臺的，客戶要求多種多樣，我們是需要支援多個數據庫的，Hibernate可以比較容易遮蔽資料庫的差異；
2. Hibernate採用面向物件的方式來寫SQL，也就是HQL和Criteria,在資料庫和Dao之間多了一層，資料庫的改動可以透過對映關係遮蔽部分影響。
3. 因為我們是要不斷的增加功能，偶然要做做系統重構，快速快發尤其重要，Hibernate的程式碼量和改動量都要比其他框架來的少，起碼經過我們的封裝已經使得用起來是很簡單了。
4. 對於效能有影響的地方和很難用Hibernate表達的地方我們會採用JdbcTemplate，或者採用View封裝一次再map到Hibernate，採用Hibernate也不排斥其他持久層框架的存在。
5. 儘量少用One to many, Many to one等功能，可能這裡不太OO，但是程式碼明瞭,不容易出問題。
6. 我們暫時還沒有遇到幾千萬的資料量那麼大的客戶，要做到那麼大資料量的時候也可以從資料庫，系統，網路各個方面來最佳化。系統推到重來也不是什麼問題。
7.Hibernate的一級快取對於長Transaction的業務複雜的程式碼反而有好處，見上面的某些分析。
8. 採用快取和靜態頁面可以消除部分效能影響，或者採用資料庫特有功能，不過取消Hibernate的二級快取，採用Spring的快取或者自己搞快取。
9. 文件多，容易解決問題，也是JPA標準的重要參考。
Hibernate不好的地方：
1. 多佔記憶體，因為他需要把domain對應的configuration都load到記憶體裡面去，多用記憶體是正常的，但是出現OutofMemerey肯定不是Hibernate的問題了，一般應用記憶體還是夠的。
2. 效能問題。Hibernate或者Ibatis也好，最終都是透過反射把ResultSet變為對應的Domain Object,跟了一下Hibernate的內部程式碼，好像是用Method.invoke來呼叫get 和set方法的，用了Cglib或者動態代理方式，這個方式肯定是要比直接呼叫get和set方法要慢的。在JDK不斷最佳化的今天，這個差距應該會縮小。 但是Ibatais應該也是透過這個方式來做，沒有看過不太肯定。Hibernate多了一個將HQL或者Domain Object轉化為SQL的過程，這個過程也會消耗一些效能，例如字串拼接，記錄Domain Object的關係等。
經過以上分析，可能Hibernate會給我帶來一定的效能損失，但是我可以透過其他辦法來彌補，記憶體就更不是問題了。但是他確實帶來了比較好的地方，因此我們會繼續用Hibernate。
所以說Hibernate適合做企業級應用，對於那種記憶體和效能要求都很高或者本來就用Ibatis的情況，其實可以選擇Ibatias或者JdbcTemplate的。就效能而言，
JdbcTemplate > Ibatis
除了快取的作用外只說DB操作，純JDBC是最快的，因為那樣沒有任何負擔，但是程式碼搞得很難看，你會這麼選擇嗎？