正確利用J2EE的各種工具

2019-11-18 16:15:40

字體：大中小

來源：轉載

供稿：網友

　　作者： BUILDER.COM

由于遵從MVC（著名的模型-視圖-控制器軟件架構）整合了若干編程措施，java 2 EnterPRise Edition（J2EE）為高度復雜和可伸縮的因特網應用程序提供了基于組件的的強大開發功能。同時，J2EE開發層次的不同滿足了各個方面的需要：某些開發者采用Enterprise JavaBean實現軟件的模型；某些企業則利用jsp實現軟件的視圖；還有些開發商則專門通過Java Servlet實現軟件中的控制器。一切都層次分明，井井有條。不是嗎？

但是層次劃分的技術復雜性卻在實際開發中給開發人員帶來了不小的壓力和負擔。多層開發模式有時會令J2EE成為龐大的、難以超越的技術集合。了解各類層次技術的特性是要花時間的，而且J2EE項目還過分要求小型開發團隊的技能資源。充分理解現有J2EE應用程序的體系結構和實現令開發人員的學習曲線非常尖銳，尤其是在考慮到開發周期的時間限制這一方面上更是如此了。結果就會導致技術開發團隊試圖“躲避”合理的J2EE實現，很有可能在將來的開發或維護中引發問題。

為了避免出現以上問題，開發者們可以根據自己的實際需要分別采用不同的J2EE技術，這樣可以更好地利用開發者的技能并讓他們更關注于任務本身。

JSP

首要的而且也可能是最早單獨運用的J2EE技術恐怕該算是JSP了。開發者們采用JSP可以創建具有Html的表示頁面和腳本小程序、JavaBean 乃至定制標簽等功能。這種聯合多種技術的JSP編程建議似乎是對單純編程技術的詛咒；J2EE教義上說的是應用程序的邏輯和顯示層從來都不應該混合起來。

然而，在有的時候，合理地唯一采用JSP會給項目開發帶來莫大的好處。鼓吹表示層和功能層分離的爭論觀點實際上會給編程帶來更大的負擔，尤其是在單一JSP用在超過兩個顯示頁面的情況下。但是體積更小更單純的JSP項目卻可能工作得更好。為了達到適度的工作量，像簡單時鐘這樣的編碼任務就變得非常容易了（參看程序清單A）。

這個例子說明了若干問題。以上程序中的代碼提供了一個用戶界面（雖然很基礎），這個界面接受用戶輸入并做出動態響應，而這就是因特網應用程序所有的基本要素了，該程序連同注釋在內只有33行代碼。要編寫一個JSP時鐘程序的更有用實現所需要的代碼就更少了：

〈%
Date d = new Date();
SimpleDateFormat sdf = new SimpleDateFormat("d MMMM yyyy, h:mm:ss a");
TimeZone zone = TimeZone.getDefault();
sdf.setTimeZone( zone );
%〉
Current date and time in the 〈b〉〈%= zone.getID() %〉〈/b〉 time zone: 〈b〉〈%= sdf.format( d ) %〉〈/b〉

只用JSP開發項目的另一優點是：JSP的學習和使用都相當方便。JSP采用了Java的語法，但在上下文環境中則完全可以用于其他服務器端開發環境??例如asp或ColdFusion等。這樣在沒有多大技術變遷的情況下就可以充分利用JSP了。

servlets
只用到Java servlets的應用程序開發是另一種區分對待J2EE模型的方式。事實上， servlets完全具有它們自己的信息記錄。許多人都沒有認識到這一點，幾年前，servlets還不過是服務器端Java開發技術的唯一選擇。CGI風格的直觀API大大減少了軟件開發的周期。采用進程內內存管理最大化服務器性能的能力贏得了開發者和系統管理員的注目。鏈式servlets的集中對功能的提高更增加了這一技術的優勢。同樣的優點使得servlets成為當前相當受到歡迎的開發平臺。集成其他的Java技術，比如通過JDBC的數據源等以及針對中小型項目的穩固解決方案也出現了。

傳統思想較重的人可能對在servlet中包括數據連接不感冒；按照J2EE規范的說法，這種復雜設計應該駐留在Enterprise Java Beans（EJB）上。當然，這種觀點對大型項目而言是正確的，但是，對那些簡單的servlet，比如顯示報告產品可用性圖表的綱要程序（示例見程序清單B）卻并不需要額外的處理。雖然以上示例訪問數據庫并動態創建圖表，但是，數據庫連接池的使用和開發者設計的資源管理卻給給予了servlet以出眾的運算速度和穩定性。產生同樣結果的完整 J2EE實現在計算上的成本卻大得多。

非Web瀏覽器式的應用程序采用servlets自有其優點。象Tomcat這樣的Servlet容器在這種情況下可以實現低成本乃至免費的開發舞臺，供開發人員營建和部署最新的無線信息平臺。Servlets通過輸出xml并且即時應用風格表單保證了用戶能在他們的移動電話或傳呼機上收到正確的格式信息。

EJB
EJB被認為J2EE應用程序中對業務邏輯的編程實現，EJB最為復雜。從表面上看， EJB代表了實體bean形式的數據庫存儲信息或者會話bean形式的服務請求。這種簡單的定義卻恰恰掩蓋了特別需要注意的幕后眾多方面；陡峭的學習曲線使得EJB項目開發進展緩慢。開發者們必須小心對付EJB容器的怪癖特性。另外，代碼的微小變化或調試經常會轉變為特別耗費精力的任務。

然而，EJB在應對大型項目開發的時候卻絕對是個好東西。由J2EE所保證的EJB容器所具有的內存管理、線程模型和交易能力允許開發者把更多的時間花在業務邏輯與代碼處理的映射上。大多數EJB容器都允許經由XML文檔對編譯后的代碼進行簡單修正。根據UML圖表為EJB產生Java源代碼的工具也有，從而簡化了從概念到實現的轉變過程。

在單獨采用EJB的時候，客戶環境的選擇也會發生變化。瀏覽器將不起作用，由于已經脫離了J2EE上下文環境，EJB此時不能引導基于Web通訊。而且客戶程序也變得更豐富：應用程序、Java和非Java、企業信息系統甚至其他的EJB。在受控環境下的項目部署??便于更新客戶應用程序的環境，比如公司內部網??是單獨采用EJB的最佳條件。

摘自：NET CHINA　　　時間：2003年1月13日

（出處：http://m.survivalescaperooms.com）

上一篇：開源密碼管理軟件

下一篇：推拉門式菜單