某一物件(單個物件)簡單的查\改\刪\增，不是批量修改、刪除，適合用Hibernate；而對於批量修改、刪除，不適合用Hibernate，這也是OR框架的弱點;要使用資料庫的特定優化機制的時候，不適合用Hibernate

補充幾點我的意見：

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

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的效能問題上了，反而沒有更多的精力關注本身就主要投