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的占位符？ 或使用使用命名參數 不要自查詢中使用字符串值來代替非常量值
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的原因
hibernate不僅僅作為持久層的orm框架存在 它除了dao層的持久化操作外 還有很多
在註解annotation已經走向主流的今天 hibernate 迅速響應 讓xml部署描述符成為可選的 Hibernate annotation 對大字段的處理只是壹個@Lob就搞定了
hibernate search對Lucene進行了輕量級的封裝 全文檢索變得非常簡單
Hibernate validator被認為是最合理的驗證方式 將驗證策略直接附在貫穿各層的領域模型domain上 不再需要哪些web框架的xml方式的驗證 代碼中不再出現大量的非空/null的判斷
jbpm Jbpm業務流程引擎的持久層采用hibenrnate來實現 要想使用jbpm hibernate是必須的 我想 業務流程管理無比重要 在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支持的好
Jboss hibernate是jboss的項目 jboss的所有項目的持久層都采用的hibernate 要知道 jsr規範組的專家們大多數是來自jboss的 在壹定程度上說 jboo引領著java的發展方向 使用hibernate 跟著jboss 不偏離java的發展方向
Gavin King 我最崇拜的偶像 他不僅發明了強大的hibernate 還搞出了同樣強大且優雅的web 應用程序框架seam 他是ejb 專家組成員之壹 是jpa規範請求的領導者 他java領域最有發言權 最權威的領袖人物之壹 現在 他領導web bean的 jsr 的發展 web bean規範的制定 全球軟件巨頭如ibm oracle bea和apache沒有壹個反對 紛紛響應 Web bean 想象起來 實在太美好了 完全的松耦合和強類型 所有的應用組件生活在壹個應用組件上下文context中 相互合作 那時將不再有各種各樣的上下文環境 不再有struts 的ActionContext 不再有spring的ApplicationContext 不再有hibernate的session 不再有持久化上下文 不再有事務上下文 不再有安全上下文 所有組件生活在壹個大家庭中 大家其樂融融 實現天下的大和平
osgi 我認為現在最值得學習的壹個技術 有了osgi 實現真正的多模塊開發 改變傳統的開發方式 現在 已經有了hibernate osgi spring dynamic modul（osgi） struts 同樣實現了對osgi的支持 目前 eclipse是基於osgi開發的 ibm的websphere v bea的所有產品都重構在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的發展方向
lishixinzhi/Article/program/Java/ky/201311/28357