Hibernate在解決性能問題方面做得非常好有了它的緩存機制使用第三方緩存和數據庫連接池就 較好的解決的性能問題但這些還不夠hibernate給了開發者足夠的自由讓開發者自己去控制性能問 題
學習了一段時間的ibatis我覺得hibernate有著ibatis無法替代的優勢
開發者都知道hibernate讓我們以oo的方式操作數據庫這讓我們看到了hibernate的強大之處 體驗到操作數據的方便但Gavin King說hibernate最耀眼之處是hibernate的緩存機制而不是以oo的 方式操作數據庫Hibernate的緩存機制不外乎是一級緩存session二級緩存sessionFactory和第三方 緩存如ehcache也就是hibernate的最強大的地方是它的緩存理解了這個才能真正的理解hibernate 緩存實在太難了我至今未能真正理解
可維護性ibatis宣揚寫sql語句它將sql語句放進一個單獨的xml文件這種方式贏得了很多開 發者的喜愛一句話方便維護但hibernate同樣具有這種功能而且比ibatis更加強大Hibernate的 命名查詢/命名參數查詢就是將hql語句放在一個單獨的xml文件之中它仍然讓人們以面向對象的方式 去操縱數據這得到大量遵循oo方式開發者的喜愛而不用在以oo的方式寫著代碼的同時然後再轉變思 維用面向關系的方式去寫那些sql語句但hibernate不僅做了這些它的native sql查詢方式完全滿 足sql語句的偏愛者它像ibatis一樣將sql語句放在配置文件之中
性能我堅信hibernate性能問題不是問題想想那麼多大中小項目都在使用hibernate你還懷 疑hibernate的性能嗎？spring整合hibernate之後在真正性能瓶頸的地方完全可以使用spring集成的 jdbc或直接寫存儲過程得了但首先得確認這實在是性能瓶頸的地方我想不應想當然的認為性能 的問題所謂的性能問題阻撓了很多人
我認為性能的好壞無外是發送sql語句的多少而已性能好發送的sql語句少性能差就是發送 大量的sql語句Hibernate在解決性能問題方面做得非常好
有了它的緩存機制使用第三方緩存和數據庫連接池就較好的解決的性能問題
但這些還不夠hibernate給了開發者足夠的自由讓開發者自己去控制性能問題
我認為開發者可以在以下幾個方面自行調優
a在查詢字符串中應該總是使用jdbc的占位符？或使用使用命名參數不要自查詢中使用字符 串值來代替非常量值
bFlush會影響性能頻繁刷新影響性能盡量減少不必要的刷新
cCascade策略在幾對幾的關系正確設置cascade策略想清楚在操作對象A的同時是否需要級聯 操作對象B比如在one to many的父子關系中刪除了父親one需級聯刪除子many這時的one這端可設 置cascade = delete這樣在刪除one時會自動刪除子但對子的操作不會影響父Cascade還有其 他的屬性值只要設置正確可提升性能
dlazy策略正確設置延遲加載策略同樣會提升性能在one to many或many to many中通常總應 該延遲加載many的一方的到內存設置了lazy = true首先發送sql語句加載自己到內存到需要 時才加載級聯對象lazy=false則會同時加載自己和級聯對象到內存
e另外還有集合的性能（setlistmaparray）都應正確設置
f正確使用第三方緩存在讀操作頻繁寫操作不多的情況使用第三方緩存可大幅度提升性能如 ehcache的緩存策略有readonlyreadwrite和notstrictreadwrite
f 隨著hibernate新版本的發布和技術的發展我相信hibernate的性能會越來越好所有性能不 是不使用hibernate的原因
hibernate不僅僅作為持久層的orm框架存在它除了dao層的持久化操作外還有很多
在注解annotation已經走向主流的今天hibernate 迅速響應讓xml部署描述符成為可選的 Hibernate annotation 對大字段的處理只是一個@Lob就搞定了
hibernate search對Lucene進行了輕量級的封裝全文檢索變得非常簡單
Hibernate validator被認為是最合理的驗證方式將驗證策略直接附在貫穿各層的領域模型domain上 不再需要哪些web框架的xml方式的驗證代碼中不再出現大量的非空/null的判斷
jbpm Jbpm業務流程引擎的持久層采用hibenrnate來實現要想使用jbpmhibernate是必須的 我想業務流程管理無比重要在soa迅速發展的今天如果實施soa項目業務流程管理是必然和必須的 因為soa就是業務和it技術的融合是業務流程管理和it基礎架構的融合在soa中業務管理是第一位 的這需要相應的技術來實現該業務流程管理開源領域的jbpm我想會是首選所以為了將來有可能實 施soa項目為了實現soa的業務流程管理應該使用hibernate
大家都知道hibernate將ejb時代的實體bean趕進了歷史而ejb的jpa標准也只不過是 hibernate的子集而已jsr規范請求的威力是巨大的沒有各種jsr規范請求就不會有各種應用程序框 架各種應用程序框架只是那些jsr規范請求的實現者jpa作為持久層的規范標准引導持久層orm框架 的方向jpa同樣以面向對象的方式操作數據庫而不是寫sql語句規范標准都完全orm不寫sql了你 還有理由不跟著它嗎？
Spring+hibernate+范型+可變參數這是一個非常強大的組合對應普通的crud操作你不再需要 重復寫那些煩人的相似的dao層和manager層的代碼僅僅需要寫一次就完成了所有大量的crud操作 Ibatis盡管也支持范型但始終沒有hibernate支持的好
Jbosshibernate是jboss的項目jboss的所有項目的持久層都采用的hibernate要知道jsr規 范組的專家們大多數是來自jboss的在一定程度上說jboo引領著java的發展方向使用hibernate跟 著jboss不偏離java的發展方向
Gavin King我最崇拜的偶像他不僅發明了強大的hibernate還搞出了同樣強大且優雅的 web應用程序框架seam他是ejb專家組成員之一是jpa規范請求的領導者他java領域最有發言 權最權威的領袖人物之一現在他領導web bean的jsr的發展web bean規范的制定全球軟件 巨頭如ibmoraclebea和apache沒有一個反對紛紛響應Web bean想象起來實在太美好了完全 的松耦合和強類型所有的應用組件生活在一個應用組件上下文context中相互合作那時將不再有各 種各樣的上下文環境不再有struts的ActionContext不再有spring的ApplicationContext不再有 hibernate的session不再有持久化上下文不再有事務上下文不再有安全上下文所有組件生活在一 個大家庭中大家其樂融融實現天下的大和平
osgi我認為現在最值得學習的一個技術有了osgi實現真正的多模塊開發改變傳統的開發 方式現在已經有了hibernate osgispring dynamic modul（osgi）struts 同樣實現了對osgi的支 持目前eclipse是基於osgi開發的ibm的websphere vbea的所有產品都重構在osgi上spring 的應用服務器同樣基於osgi在EclipseCon上osgi成為了主要的話題Osgi受到如此的待遇一點 不奇怪因為他具有無比強大的功能改變傳統的軟件開發方式Osgi采用樹設計模式將一個項目分成 多個模塊（bundle）每個模塊單獨部署單獨運行說白了就是將一個工程分成許多的插件每個插件 單獨開發重復使用實現完全的即插即用太令人激動了如果公司的軟件開發基於osgi將會有大量 的重復使用的osgi bundles公司將會積累大量的無形資產軟件開發將會越來越快而ibatis現在還沒 見到對osgi的支持
hibernate的社區非常繁榮ibatis則相對平靜
綜述hibernate還有很多優秀的特點只是我們不知道Hibernate與ibatis就像大家閨秀對小家 碧玉大家閨秀不僅具有小家碧玉的全部而且知名度更高更受尊敬更受人追捧更有發展前途小 家碧玉盡管也很有魅力但始終比上大家閨秀
Hibernate所做的不僅僅是dao層的持久化工作而ibatis恰恰如此
選擇hibernate選擇orm的王者選擇更全面的工作體驗選擇更高效的工作方式選擇更多的利潤 ;選擇Gavin King跟著領袖走選擇jboss追隨開源的潮流不偏離java的發展方向
一切都不是借口一切都在發展hibernate會越來越好
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28333.html
