學習了一段時間的ibatis，我覺得hibernate有著ibatis無法替代的優勢。

    1、開發者都知道，hibernate讓我們以oo的方式操作數據庫，這讓我們看到了hibernate的強大之處，體驗到操作數據的方便。但Gavin King說，hibernate最耀眼之處是hibernate的緩存機制，而不是以oo的方式操作數據庫。Hibernate的緩存機制不外乎是一級緩存session，二級緩存sessionFactory，和第三方緩存如ehcache.也就是hibernate的最強大的地方是它的緩存，理解了這個才能真正的理解hibernate.緩存實在太難了，我至今未能真正理解。

    2、可維護性：ibatis宣揚寫sql語句，它將sql語句放進一個單獨的xml文件，這種方式贏得了很多開發者的喜愛，一句話，方便維護。但hibernate同樣具有這種功能，而且比ibatis更加強大。Hibernate的命名查詢/命名參數查詢，就是將hql語句放在一個單獨的xml文件之中，它仍然讓人們以面向對象的方式去操縱數據，這得到大量遵循oo方式開發者的喜愛，而不用在以oo的方式寫著代碼的同時，然后再轉變思維，用面向關系的方式去寫那些sql語句。但hibernate不僅做了這些，它的native sql查詢方式，完全滿足sql語句的偏愛者，它像ibatis一樣，將sql語句放在配置文件之中。

    3、性能：我堅信，hibernate性能問題不是問題。想想那么多大中小項目都在使用hibernate，你還懷疑hibernate的性能嗎？spring整合hibernate之后，在真正性能瓶頸的地方，完全可以使用spring集成的jdbc，或直接寫存儲過程得了。但首先得確認，這實在是性能瓶頸的地方，我想，不應想當然的認為性能的問題，所謂的性能問題阻撓了很多人。

    我認為，性能的好壞無外是發送sql語句的多少而已。性能好，發送的sql語句少，性能差，就是發送大量的sql語句。Hibernate在解決性能問題方面做得非常好。

    有了它的緩存機制，使用第三方緩存和數據庫連接池，就較好的解決的性能問題。

    但這些還不夠，hibernate給了開發者足夠的自由，讓開發者自己去控制性能問題。

    我認為開發者可以在以下幾個方面自行調優：

    a、在查詢字符串中，應該總是使用jdbc的占位符？，或使用使用命名參數：，不要自查詢中使用字符串值來代替非常量值。

    b、Flush會影響性能，頻繁刷新影響性能，盡量減少不必要的刷新。

    c、Cascade策略，在幾對幾的關系，正確設置cascade策略，想清楚在操作對象A的同時是否需要級聯操作對象B，比如在one to many的父子關系中，刪除了父親one，需級聯刪除子many，這時的one這端可設置cascade = “delete”，這樣在刪除one時，會自動刪除子，但對子的操作不會影響父。Cascade還有其他的屬性值，只要設置正確，可提升性能。

    d、lazy策略，正確設置延遲加載策略同樣會提升性能，在one to many或many to many中，通常總應該延遲加載many的一方的到內存。設置了lazy = “true”，首先發送sql語句，加載自己到內存，到需要時才加載級聯對象；lazy=“false”，則會同時加載自己和級聯對象到內存。

    e、另外還有集合的性能（set、list、map、array），都應正確設置。

    f、正確使用第三方緩存，在讀操作頻繁寫操作不多的情況，使用第三方緩存可大幅度提升性能，如ehcache的緩存策略有：read-only，read-write和notstrict-read-write.

    f、 隨著hibernate新版本的發布，和技術的發展，我相信hibernate的性能會越來越好，所有性能不是不使用hibernate的原因。

    4、hibernate不僅僅作為持久層的orm框架存在，它除了dao層的持久化操作外，還有很多。

    在注解annotation已經走向主流的今天，hibernate 迅速響應，讓xml部署描述符成為可選的。Hibernate annotation 對大字段的處理只是一個@Lob就搞定了。

    hibernate search對Lucene進行了輕量級的封裝，全文檢索變得非常簡單。

    Hibernate validator被認為是最合理的驗證方式，將驗證策略直接附在貫穿各層的領域模型domain上，不再需要哪些web框架的xml方式的驗證，代碼中不再出現大量的非空/null的判斷。

    5、jbpm， Jbpm業務流程引擎的持久層采用hibenrnate來實現，要想使用jbpm，hibernate是必須的。我想，業務流程管理無比重要，在soa迅速發展的今天，如果實施soa項目，業務流程管理是必然和必須的。因為soa就是業務和it技術的融合，是業務流程管理和it基礎架構的融合。在soa中，業務管理是第一位的，這需要相應的技術來實現該業務流程管理。開源領域的jbpm我想會是首選。所以，為了將來有可能實施soa項目，為了實現soa的業務流程管理，應該使用hibernate.

    6、大家都知道，hibernate將ejb2時代的實體bean趕進了歷史，而ejb3的jpa標準也只不過是hibernate的子集而已。jsr規范請求的威力是巨大的，沒有各種jsr規范請求，就不會有各種應用程序框架，各種應用程序框架只是那些jsr規范請求的實現者。jpa作為持久層的規范標準，引導持久層orm框架的方向，jpa同樣以面向對象的方式操作數據庫，而不是寫sql語句。規范標準都完全orm，不寫sql了，你還有理由不跟著它嗎？

    7、Spring+hibernate+范型+可變參數，這是一個非常強大的組合，對應普通的crud操作，你不再需要重復寫那些煩人的相似的dao層和manager層的代碼，僅僅需要寫一次，就完成了所有大量的crud操作。Ibatis盡管也支持范型，但始終沒有hibernate支持的好

    8、Jboss，hibernate是jboss的項目，jboss的所有項目的持久層都采用的hibernate，要知道，jsr規范組的專家們大多數是來自jboss的，在一定程度上說，jboo引領著java的發展方向。使用hibernate，跟著jboss，不偏離java的發展方向。

    9、Gavin King，我最崇拜的偶像，他不僅發明了強大的hibernate，還搞出了同樣強大且優雅的web2.0應用程序框架seam.他是ejb3.0專家組成員之一，是jpa規范請求的領導者，他java領域最有發言權、最權威的領袖人物之一。現在，他領導web bean的，jsr299的發展，web bean規范的制定，全球軟件巨頭如ibm、oracle、bea和apache沒有一個反對，紛紛響應。Web bean，想象起來，實在太美好了，完全的松耦合和強類型，所有的應用組件生活在一個應用組件上下文context中，相互合作。那時將不再有各種各樣的上下文環境，不再有struts2的ActionContext，不再有spring的ApplicationContext，不再有hibernate的session，不再有持久化上下文，不再有事務上下文，不再有安全上下文，所有組件生活在一個大家庭中，大家其樂融融，實現天下的大和平。

    10、 osgi，我認為現在最值得學習的一個技術，有了osgi，實現真正的多模塊開發，改變傳統的開發方式。現在，已經有了hibernate osgi，spring dynamic modul（osgi），struts 2 同樣實現了對osgi的支持。目前，eclipse是基于osgi開發的，ibm的websphere v6.1，bea的所有產品都重構在osgi上，spring的應用服務器同樣基于osgi，在EclipseCon2007上，osgi成為了主要的話題。Osgi受到如此的待遇，一點不奇怪，因為他具有無比強大的功能，改變傳統的軟件開發方式。Osgi采用樹設計模式，將一個項目分成多個模塊（bundle），每個模塊單獨部署，單獨運行，說白了，就是將一個工程分成許多的插件，每個插件單獨開發，重復使用，實現完全的即插即用。太令人激動了。如果公司的軟件開發基于osgi，將會有大量的重復使用的osgi bundles，公司將會積累大量的無形資產，軟件開發將會越來越快。而ibatis現在還沒見到對osgi的支持。

    11、hibernate的社區非常繁榮，ibatis則相對平靜。

    綜述，hibernate還有很多優秀的特點，只是我們不知道。Hibernate與ibatis，就像大家閨秀對小家碧玉，大家閨秀不僅具有小家碧玉的全部，而且知名度更高，更受尊敬，更受人追捧，更有發展前途。小家碧玉盡管也很有魅力，但始終比上大家閨秀。

    Hibernate所做的不僅僅是dao層的持久化工作，而ibatis恰恰如此。

    選擇hibernate，選擇orm的王者，選擇更全面的工作體驗，選擇更高效的工作方式，選擇更多的利潤；選擇Gavin King，跟著領袖走；選擇jboss，追隨開源的潮流，不偏離java的發展方向。

    一切都不是借口。一切都在發展，hibernate會越來越好。