熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java開源技術 >> 正文

使用hibernate的11大優勢

2013-11-23 20:21:10  來源: Java開源技術 

  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在EclipseConosgi成為了主要的話題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/28357.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.