我眼中的J2EE

2019-11-18 12:29:39

字體：大中小

來源：轉載

供稿：網友

　　ejb是什么
　　很長時間以來，我們一直被誤導了，以為只有采用了ejb技術的系統才算真正玩了ejb。后來才明白J2EE的內涵要比ejb廣的多，是一套使用java進行企業級開發的技術規范，包含了大部分核心服務如JTA事務治理, 資源池，線程治理，還有jdbc,jsp,servlet等應用技術。而EJB僅僅是一個使用了JTA事務治理、線程治理等J2EE基礎服務的分布式的組件標準。
　　為什么需要ejb
　　按照官方的說法：
　　EnterPRise JavaBeans will make it easy to write applications. Application developers will not have to understand low-level transaction and state management details; multithreading;resource pooling; and other complex low-level APIs.
　　Declarative transaction management
　　Remoting
　　Clustering
　　Thread management
　　Instance pooling
　　Resource management
　　Security
　　Management of business objects
　　記得一個人寫文章說：“EJB最大的誘人之處是她把應用程序和服務器分開了,我們再也不用和那些服務器上的復雜的資源打交道了,什么數據庫,什么進程,線程,什么安全權限,什么套接字,都見鬼去吧,我們只需要專著于我們的商業邏輯的實現了。”
　　ejb的許諾兌現了嗎
　　ejb已經出現5、6年時間了，很多J2EE項目才也采用了ejb，sun所描述的美好前景也并沒有實現。
　　
　　1．Ejb規范本身是很復雜的，以至于沒有多少開發人員去閱讀他。Ejb總是與復雜聯系在一起的,并沒有減輕開發人員的負擔。Ejb container像一個黑盒子，ejb在里面如何運行的，機制如何，很多人都說不出ejb container是如何處理異常的，跟事務有什么聯系。
　　Ejb的運行效率如何，瓶頸在什么地方，沒有人知道。（在Oracle中的調優我們可以很精確的找出是程序甚至說哪條SQL語句的原因，Oracle配置的原因，操作系統和硬件的原因）。
　　2．Ejb的復雜意味著程序的開發效率是低的，以致于Jbuilder提供了圖形化的設計工具(一個包中的ejb只能由一個人來開發,否則合并比較麻煩) ,Xdoclet是另外一種輔助開發的方式。另外，拿entity bean來講，每次想按照不同的參數進行查詢，都要去為entity bean重新定義的一個select方法，然后編譯發布，然后在業務邏輯中調用。
　　3．Ejb是在容器中執行的，意味著我們不能像一般的javabean那樣來對待他，與javabean像比，他是一個需要其他環境的重量級實現，單元測試是很困難的。
　　4．關于entity bean,Marc fluery的文章中說Cache is the king，可是數據庫中已經有cache了，為什么還要去cache entity bean（相對于enity bean的復雜性，數據的傳輸開銷還是很小的）,僅僅是因為采用了entity bean而看起來更面向對象嗎。
　　Core j2ee patterns和一些所謂最佳實現的書都有相當一部分內容來正確和簡化使用ejb的。
　　相信Ejb 3.0在簡化方面會做了不少工作。
　　
　　為entity bean尋找理由, 構件與對象
　　一開始接觸entity bean，感到的就是復雜，開發效率低，難以維護。
　　一般來講，使用entity bean都是完成數據持久的功能。
　　后來看了hibernate,很簡單,開始困惑，總以為entity bean之所以存在，還是有他存在的理由，于是列舉了具備的安全,事務,分布式計算等方面的優點。
　　后來還是開始懷疑entity bean存在的必要,因為那些功能與優點都可以通過session bean封裝其他jdbc操作或者hibernate來實現,想來想去entity bean唯一的不同就是構件了,更像客觀存在的domain model,而不是從數據庫里面取出來的數據，entity bean使對象看起來更像真實的世界。
　　構件之所以存在，是與分布式計算分不開的。在一個系統中，你可以通過另外一個系統來調用業務邏輯和數據訪問，不同的系統通過構件來完美結合。
　　（其實torque也不錯，就是不能操作多個數據源，另外就是自己生成了相關java文件來實現or mapping的功能，而不是像hibernate那樣通過xml文件來配置實現。）
　　
　　我們需要分布式嗎，Distribution and Scalability
　　分布式意味著在網絡之間進行協調調用，意味著復雜，除非必要，就不要采用分布式技術。
　　以前以為采用ejb，程序就是分布式的，就具備了可伸縮性。
　　
　　拋開可以按功能來劃分訪問的系統，其實可伸縮性就表明了是需要Cluster的（Cluster并不完全意味著分布式，只是很多分布式體系提供了Cluster功能），而Cluster中的難點就是如何同步復制不同App Server之間的數據，而App Server是與很多資源相連的，程序執行狀態，Session變量、數據庫連接狀態，我們如何復制呢。（好不輕易理解了Oracle RAC,而我覺得Oracle的同步的資源都是內部的）。
　　
　　重量級與輕量級（ejb container vs spring）
　　在公司論壇上看到一個討論heavyweight與lightweight的區別，假如說把一項技術的規范和文檔拿出來秤，操過500克就是heavyweight，否則就是lightweight。
　　似乎heavyweight總是與復雜性聯系起來的。
　　就如同ejb container與spring。
　　
　　我們所開發的系統并不是都是分布式的，也并不都是那么復雜的，才會有spring的出現。
　　客觀的說，ejb container能夠提供的功能，spring基本上都能夠以javabean的方式實現。
　　區別還是前面說的ejb container是一個構件的容器，而spring是一個對象的容器，一個轉移對象間的耦合，把業務邏輯與安全、事務等相分離的輕量級解決方案。
　　Spring 最核心的部件就是它的Bean Container,在整個框架中扮演了一個軟總線，它使框架內部的組件按照一定的耦合度組裝起來，對外提供一個服務的接口
　　。
　　假如開發一個需要跟多個系統交互運行的分布式系統還是使用ejb吧， spring取代不了ejb。
　　對于大多數web應用，應該是一個不需要訪問其他系統的多層系統（即使可能訪問多個數據庫），采用spring把。Spring+hibernate應該是一個比較好的組合，但和ejb container相比，spring的缺點就是沒有規范。
　　這么多年來，java總是在不停的修修補補中前進，
　　
　　一切都是對象嗎， OO的困惑
　　j2ee系統的開發應該都是采用面向對象技術，要害是怎么用的問題。
　　很久以前，在重粒子空間的一篇文章里，把一切都描述為對象，整個世界是那樣的美麗。我也深信不疑。
　　由于在我們的程序中，主要是針對數據處理和流程處理的，才知道用對象來表達不是那么自然。就查到了transaction script和domain model的概念。
　　transaction script就是對表示層用戶輸入的處理程序。包括驗證和計算，存儲，調用其它系統的操作，把數據回傳給表示層。
　　domain model是所謂的域模型，跟客觀世界中的實體相對應。
　　transaction script屬于結構性思維，直觀一些，在系統中假如domain model不是很明顯，采用transaction script也是一個不錯的選擇。domain model屬于oo思維，需要較強的抽象能力，習慣了就可以能夠組織很復雜的邏輯，另外，我們必須考慮哪些行為是通用的、屬于domain model的，哪些不是，可以通過一些xxxManager或者xxxController所實現的。
　　舉一個例子，假如查看今天A銀行到B銀行的所有轉帳記錄，是列出A銀行所有帳戶對象來查看是否進行了轉帳，還是從數據庫中直接查詢今天的轉帳記錄直觀。Transaction script還是有他的用處的，可以說，所有的程序都要通過Transaction script來組織，程度不同而已。
　　這個世界，除了對象，還是有對象間的關系、行為規則和記錄（數據）的，觀察的角度不同，就可以從不同的角度來組織系統，不一定需要用對象來表示。比如一個人是一個對象，檔案所記錄他一生的活動是什么，數據，是我們關注的一個方面，我們來查檔案就夠了，而不用去問這個人。
　　
　　不排斥DB
　　在網上很多文章中，都會提到把系統想象成一個完美的oo世界，而是db只不過是一個持久化的手段而已。
　　我一直認為db也是一個完整的世界，能夠做很多事情，非凡是在效率方案。
　　所謂采用oo和j2ee的系統，模擬現實世界，注重對象間的行為和關系，比較適合oltp的應用。
　　而db則是從數據角度來進行關注一個系統的，沒有oo那么復雜的關系，處理效率很高，非凡是在大批量數據處理和長事務處理的時候有自己的優勢。在不存在明顯錯誤的前提下，db的實現一般要比oo語言要高效，只是從大的方向來講有它自己的處理范圍。
　　Oo和db需要一個適應、協作的過程。
　　你有多少系統是需要從不同數據庫之間移植的，必要的時候，在j2ee方案中采用些db技術還是不錯的選擇。
　　
　　MVC
　　Spring，struts，webwork2
　　Model
　　C/s結構下，在pb程序中，一個datawindow幾乎可以從界面交互、數據綁定以及訪問數據庫等一系列功能，你專心考慮業務實現就可以了。
　　在多層結構的程序中，這種好日子一去不復返了，因為分層，屬于接口性質的細節要靠你自己來實現，僅僅在數據方面，就出現了vo， dto，po，detached po，domain model等眾多的名詞。
　　不同的層專注于不同的功能，對于界面展現，在struts中有actionform用于顯示，業務層的數據用vo來表示，在網絡傳輸中又用到了dto（非凡的vo），數據保存又用到了po了。
　　在這種情況下，數據的完整性是一個很麻煩的問題，假如actionform可能和vo的數據不完全一致，不完全一致的內容在頁面生成的時候就丟失了，要么把vo緩存起來在需要時進行更新，要么在業務層從新query數據到vo進行更新，假如業務層是單獨的而且持久層是ejb還要再次進行查詢更新。效率很低，而且輕易出錯。
　　在hibernate中出現detached po，可以當成vo,po來用，也可以把數據傳送

上一篇：小心進行 J2EE Web Services 的測試

下一篇：深入MIDIet State Change Exception