J2EE基礎：用Hibernate企業架構的優點

j2ee

一、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之間來回猶豫不決，甚至搞不清楚的話，程式都沒有辦法寫。