最佳J2EE方案討論之O-R Mapping

2019-11-18 12:28:54

字體：大中小

來源：轉載

供稿：網友

　　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的模塊。現在需要的是等待xdoclet的下一個release。
　　
　　結論：
　　hibernate至少從文檔上超越了Entity Bean很多，我要學習hibernate。

上一篇：solaris上開發J2EE應用中文問題的解決

下一篇：J2EE應用系統內部的Web Services