J2EE 作為開發任務關鍵型企業級應用的規范整合平台，規范多、內容廣，給開發帶來諸多「麻煩」。例如實現 RDBMS 存儲，可選 JDBC、Entity Beans、JDO、O/R Mapping（TopLink、Hibernate）、XML-DBMS、JAXB 等（部分非 J2EE 規范）。為實現表示層、控制層、業務邏輯層等至少三層及層間耦合，架構師需考慮的問題極多。加上 J2EE 快速演進，構建工業強度應用更具挑戰。軟體開發無「銀彈」，J2EE 非萬能，但結合具體業務合理應用，效果可期。本文結合 JBoss 3.2.1 實戰經驗，探討四大核心原則。
脫離業務談技術優勢不夠。企業信息系統（EIS）要求穩定、安全、可靠、高效、易維護，各系統有獨特需求（如遺留系統集成），了解具體業務對架構至關鍵。
案例一：數據多來自外部數據源，經 JDBC 導入自有資料庫。低併發、小流量用 JDBC 合適；高併發、大流量、頻繁訪問 DB 則力不從心。可考慮 Entity Beans with Caches。JBoss 3.2.1 提供多種 Entity Bean 快取策略，採用「Standard CMP 2.x EntityBean」配合「D」類型 commit-option 保證與數據源同步，性能大幅提升（優於直接 JDBC）。部分 Bean 設為 read-only 可進一步改善性能。也可用 TopLink 等 O/R Mapping 技術。
案例二：數據由系統自行生成操作，建議採用 CMP Entity Beans。Entity Bean 名聲不好源於 EJB 1.1，但 EJB 2.0/2.1 大幅改進：Local Interfaces、CMR、Read-Only、Session Facade 注入活力。高併發、大流量時優勢明顯。關鍵在於性能調優，各應用服務器有專屬方案。JBoss 3.2.1 中 standardjboss.xml 提供調優入口，如 Bean Lock 策略合理使用極重要。這使我們關注業務邏輯而非底層 DB（EJB 調優在容器層，屬高端；DB 層調優則損害資料庫移植性）。
結論：須結合系統特定需求給出具體技術方案，而非孤立論述技術優劣。
設計模式在 J2EE 中關鍵。問題：自行實現模式，還是借助第三方 Framework？公司較小或不想在基礎 Framework 投入大量精力，選用成熟、穩定、兼容 J2EE 規范的框架較明智。
Framework 本質上實現並優化了具體設計模式：Business Delegate、Service Locator（Web/EJB 層服務定位器，統一管理有限資源、快取、便於移植）、Front Controller、DAO 等。主流框架：
System.out.println 的開發者是福音。雖 Java SE 有 java.util.logging，但 Log4j 簡單、高效、靈活，已成多項目首選。JBoss 3.2.1 即用 Log4j 管理日誌。原則：不宜過多框架。一、J2EE 技術演進快，過多框架不利升級維護；二、可借鑒優秀設計模式實現並改造適配項目；三、框架自身變動多，過多選用加重團隊負擔。有選擇地用成熟框架能提升效率與水平。
J2EE 要求團隊掌握多技術，現實不符。團隊通常只有美工、JSP 程式員、EJB 程式員三種角色。面對此分工，必須重視溝通、代碼一致性。建議：版本控制工具管理代碼、每天保證一個完整可運行版本。工具鏈推薦三套：
手工完成編寫、編譯、打包、部署、測試能深入理解細節，但只要有關注細節態度，選用強大工具是明智的。工具不提升技能，但能引導正確方向。如 JBuilder 9 Enterprise 的 EJB 精靈提供「Struts + EJB + Session Facade + Value Object」架構，呈現業界廣泛應用模式。
測試常被項目經理忽視（增加成本），但質量差導致後期部署運行成本遠超前期。測試分階段：
其他成功因素：Entity Bean 成功應用很大程度取決於底層 DB 設計（表結構不合理導致性能暴跌）；如何最大化挖掘團隊 J2EE 技能等，設計面極廣。
