開源物件關係對映框架hibernate 11大優勢
阿新 • • 發佈：2019-02-16
釋出時間：2009.06.19 11:42 來源：blogjava 作者：Werther
Hibernate在解決效能問題方面做得非常好。有了它的快取機制，使用第三方快取和資料庫連線池，就較好的解決的效能問題。但這些還不夠，hibernate給了開發者足夠的自由，讓開發者自己去控制性能問題。
學習了一段時間的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在解決效能問題方面做得非常好。有了它的快取機制，使用第三方快取和資料庫連線池，就較好的解決的效能問題。但這些還不夠，hibernate給了開發者足夠的自由，讓開發者自己去控制性能問題。
學習了一段時間的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的發展方向。