Hibernate和JDBC、EJB比較

參考:http://m.blog.csdn.net/article/details?id=7228061

 1、Hibernate是JDBC的輕量級的對象封裝，它是一個獨立的對象持久層框架，和App Server，和EJB沒有什麼必然的聯繫。Hibernate能夠用在任何JDBC可使用的場合，例如Java應用程序的數據庫訪問代碼，DAO接口的實現類，甚至能夠是BMP裏面的訪問數據庫的代碼。從這個意義上來講，Hibernate和EB不是一個範疇的東西，也不存在非此即彼的關係。 

2、Hibernate是一個和JDBC密切關聯的框架，因此Hibernate的兼容性和JDBC驅動，和數據庫都有必定的關係，可是和使用它的Java程序，和App Server沒有任何關係，也不存在兼容性問題。 

3、Hibernate不能用來直接和Entity Bean作對比，只有放在整個J2EE項目的框架中才能比較。而且即便是放在軟件總體框架中來看，Hibernate也是作爲JDBC的替代者出現的，而不是Entity Bean的替代者出現的，讓我再列一次我已經列n次的框架結構： 

傳統的架構： 
1) Session Bean <-> Entity Bean <-> DB 
爲了解決性能障礙的替代架構： 
2) Session Bean <-> DAO <-> JDBC <-> DB 
使用Hibernate來提升上面架構的開發效率的架構： 
3) Session Bean <-> DAO <-> Hibernate <-> DB 

就上面3個架構來分析： 
一、內存消耗：採用JDBC的架構2無疑是最省內存的，Hibernate的架構3次之，EB的架構1最差。 

二、運行效率：若是JDBC的代碼寫的很是優化，那麼JDBC架構運行效率最高，可是實際項目中，這一點幾乎作不到，這須要程序員很是精通JDBC，運用Batch語句，調整PreapredStatement的Batch Size和Fetch Size等參數，以及在必要的狀況下采用結果集cache等等。而通常狀況下程序員是作不到這一點的。所以Hibernate架構表現出最快的運行效率。EB的架構效率會差的很遠。 

三、開發效率：在有JBuilder的支持下以及簡單的項目，EB架構開發效率最高，JDBC次之，Hibernate最差。可是在大的項目，特別是持久層關係映射很複雜的狀況下，Hibernate效率高的驚人，JDBC次之，而EB架構極可能會失敗。 

四、分佈式，安全檢查，集羣，負載均衡的支持 
因爲有SB作爲Facade，3個架構沒有區別。 

4、EB和Hibernate學習難度在哪裏？ 

EB的難度在哪裏？不在複雜的XML配置文件上，而在於EB運用稍微不慎，就有嚴重的性能障礙。因此難在你須要學習不少EJB設計模式來避開性能問題，須要學習App Server和EB的配置來優化EB的運行效率。作EB的開發工做，程序員的大部分精力都被放到了EB的性能問題上了，反而沒有更多的精力關注自己就主要投入精力去考慮的對象持久層的設計上來。 

Hibernate難在哪裏？不在Hibernate自己的複雜，實際上Hibernate很是的簡單，難在Hibernate太靈活了。 

當你用EB來實現持久層的時候，你會發現EB實在是太笨拙了，笨拙到你根本沒有什麼能夠選擇的餘地，因此你根本就不用花費精力去設計方案，去平衡方案的好壞，去費腦筋考慮選擇哪一個方案，由於只有惟一的方案擺在你面前，你只能這麼作，沒得選擇。 

Hibernate相反，它太靈活了，相同的問題，你至少能夠設計出十幾種方案來解決，因此特別的犯難，究竟用這個，仍是用那個呢？這些方案之間到底有什麼區別呢？他們的運行原理有什麼不一樣？運行效率哪一個比較好？光是主鍵生成，就有七八種方案供你選擇，你爲難不爲難？集合屬性能夠用Set，能夠用List，還能夠用Bag，到底哪一個效率高，你爲難不爲難？查詢能夠用iterator，能夠用list，哪一個好，有什麼區別？你爲難不爲難？複合主鍵你能夠直接在hbm裏面配置，也能夠自定義CustomerType，哪一種比較好些？你爲難不爲難？對於一個表，你能夠選擇單一映射一個對象，也能夠映射成父子對象，還能夠映射成兩個1:1的對象，在什麼狀況下用哪一種方案比較好，你爲難不爲難？ 

這個列表能夠一直開列下去，直到你不想再看下去爲止。當你面前擺着無數的眼花繚亂的方案的時候，你會以爲幸福呢？仍是悲哀呢？若是你是一個負責的程序員，那麼你必定會仔細研究每種方案的區別，每種方案的效率，每種方案的適用場合，你會以爲你已經陷入進去拔不出來了。若是是用EB，你第一秒種就已經作出了決定，根本沒得選擇，好比說集合屬性，你只能用Collection，若是是Hibernate，你會在Bag，List和Set之間來回猶豫不決，甚至搞不清楚的話，程序都沒有辦法寫。

 

 

經常使用的數據庫操做包括：JDBC、EJB、JDO以及Hibernate。它的各有優缺點： 

   (1) JDBC：多數Java開發人員是用JDBC來和數據庫進行通訊，它能夠經過DAO模式進行改善和提升。但這種方式在大型應用程序中不容易操做使用，且維護起來至關困難。 

   (2) EJB：EJB一般是在數據持久技術上的第二個選擇，它是經過entitybeans來對數據進行持久化。首先就須要購買一個價位合理的EJB容器一J2EE應用服務器，也能夠採用開源項目的免費EJB容器，好比JBOSS。可是不少商業EJB容器的性能和技術支持不太好，在EJB中實現JDBC也比較複雜。 

   (3) JDO：JDO的出現彷佛有了一些改觀，可是，JDO沒有一個好的開源免費實現。好的產品部是商業產品，而且在國內沒有銷售和技術支持。JDO也不是一個輕量級封裝．它創建的持久層框架，很不完善。再加上JDO的標準還很不完善以及嚴重的產品分裂問題，使得不少操做方式非常煩瑣。 

   (4) Hibernate：Hibernate這種持久框架在某些方面有很大的不一樣，它不須要任何容器，提供簡單易用的API，也解決了JDO的不少缺陷。做爲一個良好的ORM ，它有以下特色： 

透明地提供對象與關係數據庫的映射，以統一的接口方式支持多種數據庫。 

緩存機制，複雜的緩存機制和鎖定策略，使針對數據庫操做大大減小。 

開源免費的License，能夠在須要的時候研究源代碼，改寫源代碼，進行功能的定製。 

輕量級封裝，避免引入過多複雜的問題，容易調試，減輕程序員的負擔。 

具備可擴展性，API開放，當自己功能不夠用的時候，能夠自行編碼擴展。 

開發者活躍，產品有穩定的發展保障。