開發J2EE應用的要領

開發J2EE應用的要領[@more@]　　J2EE，作為開發mission-critical的企業級應用的一整套規範的整合平臺。其規範之多、內容之廣，從而給開發J2EE應用帶來了很多“麻煩”。比如，為實現內容的RDBMS儲存，我們可能的方法有JDBC、Entity Beans、JDO、O/R Mapping工具（TopLink、Hibernate）、XML-DBMS、JAXB等方法（其中一些方法不是J2EE規範所包含的）。因此，為實現J2EE各層（至少有表示層、控制層、商業邏輯層等3層）以及層與層之間的耦合，J2EE系統架構師需要考慮的問題會很多。加上，J2EE本身的快速發展，給架構、開發具有工業強度的J2EE應用帶來一些難題。

　　同時，軟體開發技術從來就沒有“銀彈”，所以J2EE技術也不是萬能的。但是，如果我們在結合具體商業需求的基礎上，合理的應用好J2EE技術，其結果可想而知。本文試探從自己以往的專案經驗來探討開發J2EE應用應該遵循的幾點準測入手，以起到拋磚引玉的作用。如果能達到這一點要求，則萬分激動。

　　本文結合JBoss 3.2.1下的J2EE應用開發為例展開論述。

　　1，結合商業需求選擇合理的架構

　　如果脫離商業需求，而單獨的討論技術本身的優勢是不夠的。各項技術都有產生的特定背景，其中很多都是來自工業需求而觸動的。一般而言，企業資訊系統（EIS）都要求自己穩定、安全、可靠、高效、便於維護。同時，各個企業資訊系統都有自己獨特的要求，可能有些時候需要考慮與原有遺留系統的整合，所以瞭解各個企業資訊系統具體的商業需求對於整個系統的架構顯得很關鍵。

　　比如，如果待開發的J2EE應用系統中使用到的資料大部分來自於外在資料來源；而這些資料可能是透過JDBC直接從外在資料來源匯入到待開發的J2EE系統的Database中。對於這種情形，如果在開發過程中，僅僅使用JDBC來運算元據庫，對於小強度（併發訪問使用者少、資料流量少）的情形，顯然是比較合適的；但如果，併發訪問使用者較多、資料流量大，對Database層使用較為頻繁的情形，則顯得有些力不從心。因此，對於這種需求，我們可以考慮採用Entity Beans with Caches。打個比方，在JBoss 3.2.1中對於Entity Beans的Cache策略有多種，這時可以考慮使用，，即“Standard CMP 2.x EntityBean”，方式並採用“D”型別的commit-option來保證Entity Beans的內容與資料來源的同步，並使得系統的效能得到大大改善（同直接使用JDBC相比）。其中，可以將一些Entity Beans設定為read-only，以改善效能。

　　當然，在這裡也可以採用其他一些O/R Mapping技術，比如TopLink。

　　再比如，考慮這樣一種情形：如果待開發的企業資訊系統使用到的資料都是由系統本身生成和操作的，則建議採用：CMP Entity Beans技術。Entity Beans給大家的很壞，這可能與EJB 1.1給大家留下的壞映象有關吧。但是，EJB 2.0(或者說2.1)得到了很大的改善，Local Interfaces、CMR、Read-Only、Session Façade模式給Entity Beans注入了活力。當然，併發使用者多、資料流量很大時才會體現出使用Entity Beans的優勢。其中，有一點很關鍵：要注重Entity Beans技術的效能調優，各個應用都有自己的一套效能調優方案。對於JBoss 3.2.1，配置檔案standardjboss.xml提供了Entity Beans技術調優的入口。比如，Bean Lock策略的合理使用對於Entity Beans的調優就顯得很重要。這樣使得，我們可以更加關注於系統的商業邏輯，而不只是底層的Database（EJB調優處於EJB Container中，因此我們處在J2EE效能的高階，而不是底端，即Database層。同時，Database層的調優使得J2EE系統的資料庫移植性大打折扣。）。

　　簡而言之，要結合各個系統的特定需求和狀況給出具體的技術架構方案，而不能孤單的論述技術本身的好壞。
　　
　　2，Framework的合理選用
　　
　　設計模式在J2EE應用系統中扮演著重要的角色。因此，有一個問題擺在大家面前，是自己來實現具體的設計模式，還是藉助於Third-party Framework。如果貴公司不大，或者說公司不想在J2EE基礎應用Framework投入很多精力，選用現有的較為成熟的、穩定、與現有J2EE Specification相容的技術框架會比較明智。

　　一般而言，Framework本身，或者說J2EE平臺本身都是實現並最佳化了具體的設計模式、規則，比如業務代理、Service Locator（包括Web Tier和EJB Tier各自的服務定位器，起到統一管理有限資源、Cache相關資源的作用，便於系統移植）、Front Controller、DAO等等。現有的J2EE Framework比較豐富。比如：

　　Struts: 對於實現了Model 2型別的Framework，對於現在以及將來（隨著JSF規範、技術的成熟），選用她是一種明智之舉。目前，Struts已經發展到1.1版本。其內在的C主線、對後端資料操作方式沒有限定、集合了Apache Jakarta專案組的優秀相關專案的精華，可謂是開發J2EE應用的佳品。同時，對於具有.NET Web Forms功能的下一代J2EE平臺技術JSF而言，Struts本身可考慮到與JSF的相容和整合性。比如，透過JSP呈現表示層、Servlet呈現控制層、EJB呈現資料儲存層。各層之間，可以透過值物件、HTTP相關物件來通訊，實現J2EE相關技術的完美應用。

　　Log4j: 我想對於習慣採用“System.out.println(“”);”的讀者而言，Log4j是大家的福音。儘管Java 2 Standard Edition也具備java.util.logging包來保證日誌的輸出，但Log4j的簡單、高效、靈活已經成了很多專案的選擇。日誌，在某種程度上可以考驗系統的穩定性、正確性，所以採用可配置的Log4j（目前，Log4j已經考慮到了與java.util.logging包的相容性）是不會錯的。比如，JBoss 3.2.1本身就是藉助於Log4j來管理日誌的。

　　realMethods: 可能有些讀者還不知道這一款殺手鐧。那好，這裡就簡要作一介紹。realMethods是一開發J2EE應用的Framework，她不同於Struts(主要在於實現Model 2，J2EE應用前端)；realMethods對於J2EE應用的各個層面都有詳盡、高效的支援。同時，realMethods以前還是商用軟體，現在已經成為了Open Source的產品，因此現在可以參看其全部原始碼。
　　 BC4J: Oracle公司推出的用於Java的商業元件。其內容和外在的特點和優勢，不言而寓。
　　當然，類似的Framework很多很多。作為開發J2EE應用的團隊而言，我們需要對各種Framework加以篩選，選擇適合專案需求、團隊、公司發展方向的框架。

　　一般情況下，待開發的目標產品不宜採用過多的Framework。其一，J2EE各個技術發展很快，過多的Framework使得系統的後續升級、維護不利；其二，可以借鑑其中的好的一面，比如研究realMethods實現的相應的設計模式，並改造她以適合我們的專案需求；其三，Framework本身會有變動，如果選用過多，會給開發團隊加重負擔，從而不利於專案管理。

　　有選擇的使用現有的成熟Framework能提升大家的開發效率、開發水平。
　　
　　3，開發模式的選擇

　　開發J2EE應用要求目標開發人員能夠掌握其中的各種技術。但是，現實情況不是這樣。作為一個團隊，每個人都有自己不同的技能優勢、興趣以及悟性。同時，J2EE本身需要體現社會分工。一般情況下，我們的開發團隊不會有Specification所要求的各個開發角色。現實往往只有3種（也可能是兩種）：美工、JSP程式設計師、EJB程式設計師。面對這種分工，團隊更要注重溝通、交流，注重程式碼的一致性。

　　一般情況下，團隊要儘量採用版本控制工具管理程式碼、儘量做到每天都有一個完整的執行版本。經過一段時間，團隊都會適應這種開發模式。其中，版本控制工具一定要使用，便於程式碼的管理、控制和備份。這其中會牽扯到很多層面。比如，開發工具的選擇要考慮到版本控制工具的使用、建模工具的合理使用有助於團隊有效的溝通和交流。

　　基於現有的開發模式，個人認為這樣3套方案不錯。第一，採用Together作為建模工具、採用JBuilder作為IDE工具、採用VSS(或者CVS)作為版本控制工具、採用JBoss作為開發J2EE應用開發階段的伺服器。第二，採用WebSphere Studio整套工具。第三，採用Eclipse(或者JCreator)、Ant、XDoclets作為開發工具。

　　當然，手工完成J2EE應用的編寫、編譯、打包、部署、測試更能使開發者理解各個開發階段的具體細節。但本人認為，只要開發者有這種關注具體細節的態度，選用功能強大的建模、開發工具是明智的。開發工具不能提高開發人員的開發技能，但是她能夠引導開發人員正確的開發方向。比如,JBuidler 9 Enterprise提供的EJB精靈具有的“Struts + EJB + Session Façade + Value Object”等功能呈現了業界廣泛應用的J2EE構架方式。

　　4，注重各個階段的測試工作

　　測試工作往往是很多專案經理忽視，不願意去花費時間、費用的內容，因為那樣會增加專案的成本。但是，他們忽視了，專案的完成質量往往對專案的成本有很大的關係。比如，如果軟體質量很差，並沒有經歷測試階段，其後期部署、執行所帶來的費用會遠遠超過前期的費用。
　　 測試是分階段的。單元測試，比如藉助於JUnit，來保證功能正確等內容。整合測試，來保證系統沒有記憶體洩漏等內容。其中，Optimizeite Suite Enterprise對於完成Profiler、Code Coverage、Thread Debugger等內容很有幫助。我記得，我寫的一個Swing桌面應用存在內容洩漏，但是想了很多辦法都沒有解決問題。後來，採用Profiler獲得了答案。因此，現在開發應用，我們很多時候都採用Optimizeite Suite Enterprise作為測試工具。尤其是，在做整合測試過程中，檢查系統的記憶體洩漏、效能很有幫助。

　　測試是分型別的。壓力測試、效能測試。就目前對支援J2EE應用的測試而言，並沒有很好的測試工具。但是，一般情況下，藉助於Rational Robot也能夠取得不錯的效果。

　　 當然，成功開發J2EE應用的因素有很多。比如，Entity Beans的成功應用很大程度上與底層Database的設計有關係（如果表結構設計設計的不合理，將導致Entity Beans效能的急劇下降）；如何最大化挖掘、提升團隊各個成員的J2EE技能。等等這些，設計面很廣。