J2EE的標準是CMP Entity Bean，而實際應用中受到詬病最多的也是它。我們化了整整半年時間研究CMP2.0的
開發方法，目前總算能夠將代碼量減少到70%，并且有希望減少到90%。我曾經很滿足現有的成績，但是當我真正地閱讀了hibernate后，對CMP2.0的信心徹底動搖了。
hibernate至少比CMP2.0有以下優點： 1. 兼容性。
規范一模一樣，實現各有不同，這是CMP的現狀。用第三方O-R Mapping工具可以解決這個問題。
2. 保護智力投資。 在了解了Orion, Weblogic, JBoss的CMP實現后，我不愿意再去學習Websphere 或者Resin的實現了。
3. 性能。 a. local v.s. remote， hibernate、JDO、Castor都是本地調用，CMP2.0雖然也有Local接口，但是Web層還是需要通過Remote接口訪問EJB層的數據,序列化、
網絡調用、創建大量的對象，都是性能降低的原因。
b. transaction，J2EE提出了一個全新的事務模型（method-based descriptor)，對
程序員的開發確實是個“簡化”，記得一本教程建議所有的EJB方法都用Required。但這樣的結果是什么？ 性能極度降低！互鎖！沒有辦法，我們只有再去調節各個方法的Transaction屬性，然后又出現 新的互鎖...
新的事務模型是不成功的。它試圖簡化問題，卻引入了更為嚴重的問題。各家廠商的Transaction實現也不盡相同，有的支持Optimistic Lock，有的在VM中同步Entity對象，又是兼容性的一大敵。
hibernate沒有試圖創造一個更新的模式，相反，它沿用了傳統
數據庫的Transaction編程模式，在對J2EE的Transaction傷透腦筋后看到它，真是十分親切，感覺自己確實在編程，而不是碰運氣填代碼了。
4. 動態Query。 Entity Bean很難實現動態Query，這是因為它基于代碼自動生成技術，即最終的執行代碼是在部署編譯時生成的。hibernate則有根本的改變，它基于reflection機制，運行時動態Query是很自然的事。另外，hibernate幾乎支持所有的
SQL語法，傳統數據庫可以做的它就可以做。
5. 發展速度。 I have a dream, 有一天Entity Bean會變得很好。但至少目前來看，Entity Bean是一個不完善的產品，它是大公司政治斗爭和妥協的產品，而且習慣性將一些問題“無限期擱置”，典型的例子就是Query（之所以不提其他問題，是因為其他都是Entity Bean的致命傷：））
形成強烈反差的是，hibernate的核心程序員只有一人，但它改進的速度確是Entity Bean無法企及的。
6 . 繼承和多態。 OO語言的精華在Entity Bean這里是行不通的，我曾經自我安慰將Entity Bean看做一個“內存中的數據表”，才找到了一點平衡。
但當我看到hibernate時，又開始不平衡了。
另外，CMP2.0也有一些缺點是可以彌補的 1. 代碼維護 大量的接口文件和配置文件，開發和維護的工作量很大。
解決途徑：采用xdoclet,可以自動產生眾多的接口和配置文件，甚至facade, delegate等高級模式。
至少目前來看，hibernate的缺點有 1. 代碼維護 hibernate提供了自動生成mapping文件“框架”的工具，但還需要手工調節。而這類開發，能想到的最佳模式就是xdoclet的（代碼+注釋）的模式了。幸好，hibernate的程序員已經向xdoclet項目增加了hibernate的模塊�，F在需要的是等待xdoclet的下一個release。
結論：
hibernate至少從文檔上超越了Entity Bean很多，我要學習hibernate。
