J2EE 企業級應用架構設計原則：從業務需求出發的技術選型與工程實踐

J2EE 規範龐雜 (JDBC、EJB、JDO、O/R Mapping、JAXB…)，架構師面臨海量技術選型組合。無「銀彈」能解決所有問題，但遵循核心原則、結合具體業務場景，可構建具工業強度的系統。本文沉澱實戰經驗，闡述四大開發原則。

原則一：業務需求驅動架構選型，而非技術優先

脫離業務談技術優劣無意義。企業資訊系統 (EIS) 核心诉求：穩定、安全、可靠、高效、易維護，且各系統有獨特約束 (如遺留系統整合)。

場景 A：資料多數來自外部資料源，經 JDBC 導入自有資料庫

• 低併發/小流量：純 JDBC 輕量足夠
• 高併發/大流量/頻繁存取：JDBC 連線池壓力大 → 採 Entity Beans + Cache 策略。
  • JBoss 3.2.1 提供多種 Entity Bean 快取策略，推薦 Standard CMP 2.x EntityBean 搭配 Commit Option D：確保 Bean 與資料源同步，大幅提升效能
  • 唯讀實體標記 read-only 進一步優化
  • 或採 TopLink 等 O/R Mapping 框架

關鍵：EJB 調優在容器層 (高層)，而非資料庫層 (低層)，保持資料庫移植性。

場景 B：資料由系統自行產生與操作

• 推薦 CMP Entity Beans (EJB 2.0/2.1 大幅改良)
• Local Interfaces、CMR、Read-Only、Session Facade 模式注入活力
• 高併發/大流量時優勢明顯
• 核心在 效能調優：各應用伺服器有專屬方案 (JBoss standardjboss.xml)，Bean Lock 策略合理運用至關重要

結論

無最好技術，只有最適合業務場景的架構。技術服務於業務，而非反之。

原則二：審慎選用成熟框架，避免框架氾濫

設計模式在 J2EE 中核心地位，面臨「自行實現」vs「引入第三方框架」抉擇。中小團隊或不願投入基礎框架研發者，引入成熟、穩定、相容 J2EE 規範的框架較明智。

主流框架評估

框架選用鐵律

1. 不宜過多：升級維護困難、團隊負擔重、專案管理風險大
2. 取其精華：研究優秀框架 (如 realMethods) 的設計模式實現，改造適配專案需求
3. 穩定優先：框架本身會變動，核心框架鎖定版本

工具提升效率，但無法替代技能成長。保持對細節的關注態度，善用強大工具引導正確開發方向 (如 JBuilder EJB 精靈產出「Struts + EJB + Session Facade + Value Object」標準架構)。

原則三：適應團隊現狀的開發模式與工具鏈

理想團隊擁有規範定義的所有角色，現實常只有：美工、JSP 程式員、EJB 程式員。關鍵在於：

• 溝通協作：建模工具 (Together) 輔助有效溝通
• 版本控制**：必須使用 (VSS/CVS/SVN)，每日產出可運行版本
• 工具鏈三大推薦組合：
  1. Together (建模) + JBuilder (IDE) + VSS/CVS (版控) + JBoss (開發期伺服器)
  2. WebSphere Studio 全套工具
  3. Eclipse/JCreator + Ant + XDoclet

手工打包部署有助理解細節，但生產效率下工具鏈不可或缺。

原則四：分階段、分類型的測試體系，質量是成本的守門員

測試常被項目經理忽視 (增加前期成本)，但質量差導致的部署/運行成本遠超前期投入。

階段測試

• 單元測試：JUnit 保證功能正確性
• 整合測試：檢測記憶體洩漏、效能瓶頸。OptimizeIt Suite Enterprise 的 Profiler、Code Coverage、Thread Debugger 極具價值 (曾助解決 Swing 應用記憶體洩漏)

類型測試

• 壓力/效能測試：J2EE 專用工具缺乏，Rational Robot 可取得不錯效果

其他關鍵成功因子

• Entity Beans 成敗繫於底層資料表設計合理性 (結構不佳導致效能崩盤)
• 最大化挖掘團隊成員 J2EE 技能
• 持續關注技術演進與架構演化

總結

J2EE 開發無標準答案，但遵循四大原則可大幅降低失敗風險：

1. 業務驅動架構，技術服務場景
2. 精選成熟框架，拒絕框架膨脹
3. 適配團隊現狀，建立工程化開發模式
4. 測試前置分層，質量內建而非事後補救

技術服務於商業價值，架構師的核心價值在於「在約束中尋找最優解」。