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