近日，在JavaEye論壇中，看了Ibatis和Hibernate的帖子，看后，心里覺得的憋悶，不說不快, 這里，我想更細化一下：
1. 庫表的復雜度，首先取決于需求，不取決于設(shè)計，設(shè)計能力強的人，也要遵守庫表設(shè)計的規(guī)范，從巴克斯三個范式上，原則上也要遵守。不能說用了Hibernate,自己的庫表設(shè)計能力就強了。不能為了用Hibernate，就去一味批判復雜的關(guān)系不對。復雜的關(guān)系設(shè)計對不對，首先取決于是否有復雜的需求，其次才取決于設(shè)計者的能力。
2. 只要你用的是關(guān)系數(shù)據(jù)庫，就必須要明白，為什么叫關(guān)系數(shù)據(jù)庫，而不叫面向?qū)ο髷?shù)據(jù)庫，把面向?qū)ο蟮哪切┯^點，拿到庫表設(shè)計上，后期維護和調(diào)優(yōu)上，你要擔起責任，不能讓開發(fā)人員替早期決策人員擦屁股。我見過有的人，打著OO和擴展性的旗號，硬生生的把一個表，拆成了三個表，而這三個表，本來，只需要增加一個類型字段，再做一些冗余，就可以是一個表?，F(xiàn)在查詢時，還要把這三個表Union到一塊來查。當需求變更時，增加一個字段，不僅要改變?nèi)齻€類，還要改變?nèi)齻€表，簡直是亂倫。
3.One-One的庫表設(shè)計，對于DBA來講，并不是一個best practice的設(shè)計。不能為了Hibernate，刻意把大表拆成小表，再用幾個小類，做成One-One的映射關(guān)系。整體性，是不能隨便的分割，畢竟開發(fā)人在調(diào)試、測試和維護的時候，更喜歡看數(shù)據(jù)庫里的數(shù)據(jù)，本來一個SQL，就查出來，現(xiàn)在要到多個表中去查。
4. 增刪改存的實體維護
Ibatis比不上Hibernate，說實在話，現(xiàn)在讓我寫SQL來維護一個多對多關(guān)系的實體維護，我都要考慮上半天，別說寫代碼了。
5. 你需要寫原生SQL嗎
首先你要確認，你項目的要求不需要寫原生SQL，再來講Ibatis和Hibernate的好壞，在寫原生SQL上，特別是動態(tài)生成的SQL，ibatis比Hiberante有得一拼，ibatis就像一個模板一樣，將SQL寫在配置文件當中，集中配置，特別方便技術(shù)領(lǐng)導者監(jiān)控項目成員寫的SQL好壞，而且沒有什么學習曲線，就寫SQL就完事了。
有人會說，Hibernate也支持寫SQL，但是寫代碼當中，就失去了原來基于Hibernate的DAO的簡潔性。那個DAO一點也不簡潔，如果你將動態(tài)拼SQL的代碼也放在DAO當中，那個DAO就會充斥大量的If 。。Else。。之類的語句，一坨一坨的，非常的壯觀。
還有人會說，Hibernate也支持命名查詢，將SQL寫在映射文件當中，但是命名查詢，只支持占位符固定的情況，也就是說，where a = ? and b = ? and c=?，是三個問號，就是三個問號，傳參時，少一個都不行。但是很多項目的查詢，都是動態(tài)的，也就是說用戶選了這個查詢條件，才會生成這個占位符的。
Hibernate辦不到。
還有人會說，我自己用Hibernate寫一個框架，也可以做到，那你寫的可能比Ibatis好，也可能差，你要造輪子，誰來攔不著。
5. 調(diào)優(yōu)
早期調(diào)優(yōu)，有些Bad SQL，其實在code review階段，只要看看Ibatis的SQL配置文件，就可以扼殺掉的，如果使用HSQL，可能不會被發(fā)現(xiàn)，因為它不僅隱藏在代碼當中，有的時候，還需要程序跑起來，通過日志打印出SQL或者通過其它工具如P6Spy來看的出來。
后期調(diào)優(yōu)，既然是調(diào)優(yōu)，我想就一定是遇到了瓶頸，可能要在庫表上做冗余，可能要檢查那些Bad SQL，可能要修改代碼，可能要動用DBA層次上的一些調(diào)優(yōu)手段，那么調(diào)優(yōu)越深入，Ibatis的優(yōu)勢就越能體現(xiàn)出來，比如說增加臨時表，中間表，增加冗余字段等。
6. 開發(fā)速度
如果項目當中，沒有一個Hibernate高手，你的項目又相對的復雜，不僅有復雜的庫表關(guān)系，還有大量的報表查詢，那么使用Hibernate，速度上遜于Ibatis.
問題在于，怎么樣算是一個Hibernate高手，別看論壇上，那么多人，群情激奮的在說Hibernate的好，有誰真的是高手？
我認識一個人，連Hibernate的命名查詢、悲觀鎖、樂觀鎖之類的，都不清楚，還在那說：“說Hibernate不好的人，只是他不會用Hibernate，高手使用EJB也一樣用的很順溜“，我這輩子，最最討厭的就的這樣的人，人家明明用Spring很簡單，很快樂，為什么要用EJB，充高手。換過來，項目使用Ibatis來做動態(tài)查詢，很快的就解決問題了，為什么要去學Hibernate里面高深的東東，是不是這樣就是高手了？
7. 平臺移植性
如果你的項目要做產(chǎn)品，而且打算基于多個數(shù)據(jù)庫平臺的發(fā)布，使用Hiberante是沒有說了。
8. 維護性
如果不考慮移植性，Ibatis的可維護不差于Hibernate，庫表變動引起實體類變動時，HSQL也會有改動，有人說不用改，說這話的那個人可能整天只會有select * ，如果ibatis也是這樣寫，也不用動了。
HSQL好閱讀嗎，F(xiàn)rom order，確實很簡單，但實際當中，這跟拿HelloWord做例子，有什么區(qū)別？
9. 我在實際項目當中的運用
項目背景：
我自己從Hibernate2開始使用，我現(xiàn)在也不認為我是Hibernate高手，我也沒有時間去鉆研Hibernate，更深的東西，我也不喜歡坐在開發(fā)人員旁邊老半天，去幫他們解決Hibernate遇到的問題，因為我自己還有很多事要做。
我的項目當中，在Hibernate方面，還有一個比我更強的人，他也很煩去看Hibernate打印出來的sql，看上老半天，再調(diào)上老半天，項目進度，嗖嗖的過去了。
水平越高的人，任務(wù)越重，很少有時間和耐心去解決一般性的問題。
最終的運用：
在基于Spring的容器事務(wù)管理之下，
增、刪、改、存及在事務(wù)中的查詢，使用Hibernate。
非事務(wù)性的查詢及報表，都用Ibatis，維護非常的直觀方便，開發(fā)速度上也快很多。
我覺得現(xiàn)在技術(shù)換代很快，使用一項技術(shù)，首先是要快速的解決問題，然后要學習他的思想，那些整天死抱著Hibernate，自認為學習到ORM的設(shè)計技巧的人，就去繼續(xù)的學吧。
我已經(jīng)會用Hibernate的一些方面，我覺得夠用就行了，犯不上，天天鉆研HSQL，如果有時間，我覺得躺在草坪上看看Unix的編程藝術(shù)，看看代碼大全，看看Oracle的編程藝術(shù)，比看Hibernate的SB書要愜意多了。
簡單能夠帶來快樂，用過EJB，再用Spring的人，都有體會，那簡直是一種思想上的重生。
Ibatis的設(shè)計者認為，在新的項目當中，可以使用Hibernate，在舊的遺留項目當中，可以使用Ibatis，不明白，他為什么說這樣的話，這與新舊項目有什么區(qū)別？ 新的項目就真的可以使用Hibernate嗎。