第二，Hibernate是與JDBC密切相關的框架，所以Hibernate與JDBC驅動的兼容性與數據庫有關，但與使用它的Java程序無關，不存在兼容性問題。
第三，Hibernate不能和Entity Bean直接比較，只能放在整個J2EE項目的框架下比較。甚至在軟件的整體框架中，Hibernate是作為JDBC的替代品出現的，而不是實體Bean的替代品。讓我把我已經列了n遍的框架結構再列壹遍:
傳統建築:
1)會話Bean & lt-& gt；實體Bean & lt-& gt；分貝
解決性能障礙的替代架構:
2)會話Bean & lt-& gt；道& lt-& gt；JDBC <-& gt；分貝
使用Hibernate提高上述架構開發效率的架構:
3)會話Bean & lt-& gt；道& lt-& gt；冬眠& lt-& gt；分貝
分析以上三種架構:
1，內存消耗:JDBC架構2無疑是最節省內存的，其次是Hibernate架構3，EB架構1最差。
2.運行效率:如果對JDBC代碼進行優化，JDBC架構可以以最高的效率運行，但在實際項目中，這幾乎無法做到，這需要程序員對JDBC非常精通，使用批處理語句，調整PreapredStatement的批處理大小和Fetch Size參數，必要時采用結果集緩存。壹般程序員做不到這壹點。所以Hibernate架構表現出最快的運行效率。EB架構的效率將遠非完美。
3.開發效率:在JBuilder和簡單項目的支持下，EB架構的開發效率最高，其次是JDBC和Hibernate。但是在大型項目中，尤其是持久層的關系映射非常復雜的情況下，Hibernate的效率出奇的高，其次是JDBC，EB架構很可能會失敗。
4、分布式、安全檢查、集群、負載均衡支持
以SB為門面，三個架構沒有區別。
4.學習EB和Hibernate有什麽困難？
EB的難度在哪裏？不是在復雜的XML配置文件中，而是在不小心使用EB時，會出現嚴重的性能障礙。所以難點在於妳需要學習很多EJB設計模式來避免性能問題，妳需要學習App Server和EB的配置來優化EB的運行效率。在EB的開發中，程序員的大部分精力都放在了EB的性能上，而沒有更多的精力去關註對象持久層的設計，他主要關註的就是這個。
Hibernate的難度是什麽？Hibernate本身並不復雜。其實Hibernate很簡單，但是Hibernate太靈活了。
當妳用EB實現持久層的時候，妳會發現EB是如此的笨拙，妳根本沒有選擇的余地，所以妳不用花精力去設計方案，平衡方案的質量，也不用費心去考慮選擇哪個方案，因為擺在妳面前的只有壹個方案，妳只能去做，妳沒有選擇。
Hibernate恰恰相反，太靈活了。妳可以針對同壹個問題設計至少十幾個解決方案，所以用這個用那個特別難。這些方案有什麽區別？它們的操作有何不同？哪個操作效率更好？僅僅是生成主鍵，就有七八種方案供妳選擇。妳尷尬嗎？集合屬性可以是集合、列表和包。哪個效率最高，妳尷尬嗎？您可以使用叠代器或列表進行查詢。哪個更好？有什麽區別？妳尷尬嗎？可以直接在hbm中配置復合主鍵，也可以自定義CustomerType，哪個更好？妳尷尬嗎？對於表，可以選擇映射單個對象、父子對象或1:1的兩個對象。什麽情況下，哪個方案更好？妳尷尬嗎？
這個清單可以壹直列下去，直到妳不想再看下去。當無數眼花繚亂的計劃擺在妳面前時，妳會感到幸福嗎？還是傷心？如果妳是壹個負責任的程序員，那麽妳會仔細研究每種方案的區別，每種方案的效率，每種方案的適用場合，妳會覺得自己卡在裏面拔不出來。如果用EB的話，第壹秒就已經做了決定，根本沒有選擇的余地。例如，您只能使用集合。如果用Hibernate，會在包、列表、集合之間來回猶豫，即使不清楚，也沒辦法寫出程序。