jdbc與hibernate的優缺點比較(轉載的精髓)

 

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

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

三、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個架構來分析：

                    1、內存消耗：采用JDBC的架構2無疑是最省內存的，Hibernate的架構3次之，EB的架構1最差。

                    2、運行效率： 如果JDBC的代碼寫的非常優化，那么JDBC架構運行效率最高，但是實際項目中，這一點幾乎做不到，這需要程序員非常精通JDBC，運用Batch語 句，調整PreapredStatement的Batch Size和Fetch Size等參數，以及在必要的情況下采用結果集cache等等。而一般情況下程序員是做不到這一點的。因此Hibernate架構表現出最快的運行效率。 EB的架構效率會差的很遠。

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

                    4、分布式，安全檢查，集群，負載均衡的支持 由於有SB做為Facade，3個架構沒有區別。

四、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與Hibernate在性能上相比，JDBC靈活性有優勢。而Hibernate在易學性，易用性上有些優勢。當用到很多復雜的多表聯查和復雜的數據庫操作時，JDBC有優勢。

相同點：

◆兩者都是JAVA的數據庫操作中間件。

◆兩者對於數據庫進行直接操作的對象都不是線程安全的，都需要及時關閉。

◆兩者都可以對數據庫的更新操作進行顯式的事務處理。

不同點：

◆使用的SQL語言不同：JDBC使用的是基於關系型數據庫的標准SQL語言，Hibernate使用的是HQL(Hibernate query language)語言

◆操作的對象不同：JDBC操作的是數據，將數據通過SQL語句直接傳送到數據庫中執行，Hibernate操作的是持久化對象，由底層持久化對象的數據更新到數據庫中。

◆數據狀態不同：JDBC操作的數據是“瞬時”的，變量的值無法與數據庫中的值保持一致，而Hibernate操作的數據是可持久的，即持久化對象的數據屬性的值是可以跟數據庫中的值保持一致的。

JDBC與Hibernate讀取性能

1、JDBC仍然是最快的訪問方式，不論是Create還是Read操作，都是JDBC快。

2、Hibernate使用uuid.hex構造主鍵，性能稍微有點損失，但是不大。

3、Create操作，JDBC在使用批處理的方式下速度比Hibernate快，使用批處理方式耗用JVM內存比不使用批處理方式要多得多。

4、讀取數據，Hibernate的Iterator速度非常緩慢，因為他是每次next的時候才去數據庫取數據，這一點從觀察任務管理器的java進程占用內存的變化也可以看得很清楚，內存是幾十K幾十K的增加。

5、讀取數據，Hibernate的List速度很快，因為他是一次性把數據取完，這一點從觀察任務管理器的java進程占用內存的變化也可以看得很清楚，內存幾乎是10M的10M的增加。

6、JDBC讀取數據的方式和Hibernate的List方式是一樣的（這跟JDBC驅動有很大關系，不同的JDBC驅動，結果會很不一樣），這 從觀察java進程內存變化可以判斷出來，由於JDBC不需要像Hibernate那樣構造一堆Cat對象實例，所以占用JVM內存要比 Hibernate的List方式大概少一半左右。

7、Hibernate的Iterator方式並非一無是處，它適合於從大的結果集中選取少量的數據，即不需要占用很多內存，又可以迅速得到結果。另外Iterator適合於使用JCS緩沖。最終結論：

由於MySQL的JDBC驅動的重大缺陷，使得測試結果變得毫無意義，不具備任何參考價值，只是我們能夠大概判斷出一些結論：

一、精心編寫的JDBC無論如何都是最快的。

二、Hibernate List和Iterator適用的場合不同，不存在孰優孰劣的問題

我個人認為Hibernate Iterator是JDBC Result的封裝，Hibernate List是Scrollable Result的封裝，所以我推測，如果在Oracle或者DB2上面做同樣的Read測試，如果結果集小於FetchSize，4者在速度上應該都不會有 差別；如果結果集大於FetchSize的話，但是不是FetchSize的很多倍，速度排名應該是：

JDBC Scrollable Result (消耗時間最少) < Hibernate List < JDBC Result < Hibernate Iterator

如果結果集非常大，但是只取結果集中的部分記錄，那么速度排名：

JDBC Result < Hibernate Iterator < JDBC Scrollable Result < Hibernate List

為了避免造成誤導，我最后強調一下我的結論：

一、“精心編寫”的JDBC一定是性能最好的

實際上，不管CMP，Hibernate，JDO等等，所有的ORM都是對JDBC的封裝，CMP則是一個重量級封裝，JDO中度封 裝，Hibernate是輕量級的封裝。從理論上來說，ORM永遠也不可能比JDBC性能好。就像任何高級語言的運行性能永遠也不會好過匯編語言一個道 理。

對於Create和Update操作來說，由於普通的Java程序員未必會使用JDBC的Batch的功能，所以Hibernate會表現出超過JDBC的運行速度。

對於Read的操作來說，ORM普遍都會帶有雙層緩沖，即PrepreadStatement緩沖和ResultSet緩沖，而JDBC本身沒有緩 沖機制，在使用連接池的情況下，一些連接池將會提供PrepreadStatement緩沖，有的甚至提供ResultSet緩沖，但是普遍情況 下，Java程序員一般都不會考慮到在寫JDBC的時候優化緩沖，而且這樣做也不太現實，所以在某些情況下，ORM會表現出超過JDBC的Read速度。

二、Hibernate List和Iterator方式的比較

JDBC與Hibernate在測試中想要重點考察的方面是 List與Iterator，但是由於JDBC驅動問題，結果變的很不可信，不過仍然可以得到一些有用的結論。

Read操作包括兩步：第一步是把數據庫的數據取出，構造結果集，把數據放入到結果集中；第二步是遍歷結果集，取每行數據。

List方式是1次性把所有的數據全部取到內存中，構造一個超大的結果集，主要的時間開銷是這一步，這一步的時間開銷要遠遠超過JDBC和 Iterator方式下構造結果集的時間開銷，並且內存開銷也很驚人；而對結果集的遍歷操作，速度則是非常的驚人（從上面的測試結果來看，30萬記錄的內 存遍歷不到100ms，由於這一步不受JDBC影響，因此結果可信）。因此，List方式適合於對結果集進行反復多次操作的情況，例如分頁顯示，往后往前 遍歷，跳到第一行，跳到最后一行等等。

Iterator方式只取記錄id到內存中，並沒有把所有數據取到內存中，因此構造結果集的時間開銷很小，比JDBC和List方式都要少，並且內 存開銷也小很多。而對結果集的遍歷的操作的時候，Iterator仍然要訪問數據庫，所有主要的時間開銷都花在這里。因此，Iterator方式適合於只 對結果集進行1次遍歷操作的情況，並且Iterator方式特別適合於從超大結果集中取少量數據，這種情況Iterator性能非常好。

另外Iterator方式可以利用JCS緩沖，在使用緩沖的情況下Iterator方式的遍歷操作速度將不受數據庫訪問速度的影響，得到徹底的提 升。Hibernate Iterator JCS方式應該是最快的，Hibernate List速度與JDBC比較接近，而Hibernate Iterator速度還是慢的離譜。另外JDBC和List受到Fetch Size的影響很大，當Fetch Size大於50的時候，速度有非常顯著的提升，而Hibernate Iterator的速度似乎不受Fetch Size的影響