J2EE，作為開發mission-critical的企業級應用的一整套規范的整合平臺，規范多、內容廣，從而給開發J2EE應用帶來了很多“麻煩”。比如，為實現內容的RDBMS存儲，我們可能的方法有JDBC、Entity Beans、JDO、O/R Mapping工具(TopLink、Hibernate)、xm l-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.xm l提供了Entity Beans技術調優的入口。比如，Bean Lock策略的合理使用對于Entity Beans的調優就顯得很重要。這樣使得，我們可以更加關注于系統的商業邏輯，而不只是底層的Database(EJB調優處于EJB Container中，因此我們處在J2EE性能的高端，而不是底端，即Database層。同時，Database層的調優使得J2EE系統的數據庫移植性大打折扣。)。

　　簡而言之，要結合各個系統的特定需求和狀況給出具體的技術架構方案，而不能孤單的論述技術本身的好壞。

　　2.fr amework的合理選用

　　設計模式在J2EE應用系統中扮演著重要的角色。因此，有一個問題擺在大家面前，是自己來實現具體的設計模式，還是借助于Third-party fr amework。如果貴公司不大，或者說公司不想在J2EE基礎應用fr amework投入很多精力，選用現有的較為成熟的、穩定、與現有J2EE Specification兼容的技術框架會比較明智。