開發J2EE應用遵循的關鍵問題

開發J2EE應用遵循的關鍵問題

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版本。其內在的MVC主線、對後端數據操做方式沒有限定、集合了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技能。等等這些，設計面很廣。