在現代技術棧下，何時使用 EJB、是否必要 仍是架構團隊核心決策。本文提供七大技術判斷準則、兩個實戰案例 (正確/錯誤使用) 深度剖析，助您做出理性架構選型。
| # | 關鍵問題 | 核心考量 | EJB 價值 |
|---|---|---|---|
| 1 | 需將商務邏輯與面向外網的 Web 層物理隔離 (DMZ/防火牆)？ | 核心資產 (演算法、數據結構) 不可暴露於 Web 伺服器 | EJB 部署於內網應用服務器，Web 層僅持有 Stub/Proxy，物理隔離天然實現 |
| 2 | 需支援多類型客戶端 共享同一商務邏輯與數據？ | Web/HTML、Rich Client、Mobile、Web Service、Batch Job 同時存取 | EJB 集中封裝商務邏輯與數據存取，多客戶端共享單一實現，避免重複代碼與資料庫鎖競爭 |
| 3 | 共享數據需並發讀寫 且要求強一致性？ | 多用戶同時修改同一記錄，傳統方案需自行處理 DB 鎖/同步，極易出錯 | 容器自動管理事務與 DB 內部鎖，開發者無感知即得 ACID 保障 |
| 4 | 需跨多個異構資料源 實現全域事務 (兩階段提交)？ | 訂單寫 Oracle + 出貨單寫 CICS (via MQSeries)，任一失敗全回滾 | EJB 容器 (WebSphere 企業版等) 提供 XA 協調器，支援多資料源 2PC，避免自寫事務管理器 |
| 5 | 需方法級安全控制 並與 Web 層安全無縫整合？ | 保險業法規要求：特定角色僅能存取特定物件/方法，而非整張表 | EJB 宣告式方法級安全 + 容器安全上下文傳播 (Web 身份透傳至 EJB)，細粒度、集中管理 |
| 6 | 架構有標準化、輕量化、組件化、廠商中立 戰略需求？ | 避免鎖定 WebLogic/WebSphere/JBoss，長期降低遷移成本 | EJB 3.x 註解式開發輕量化，標準 API 理論可跨容器部署 (實際仍有細節差異) |
| 7 | 系統需水平擴展 支撐高併發/高可用 (叢集、負載均衡、Failover)？ | 胖客戶端/單機架構無法支撐萬級用戶、7x24 運營 | EJB 叢集、負載均衡、狀態複制 (SFSB) 為擴展性提供骨架 |
場景：單一 Web 應用，單一資料庫，無外部整合，無細粒度安全需求，團隊僅熟悉 Servlet/JSP/JDBC。
錯誤決策：引入 EJB 實現資料映射 (CMP Entity Bean)。
後果：
教訓：單機 Web 應用、單一資料源、無分布式需求 → 不要用 EJB。POJO + Spring + iBatis/MyBatis/JPA 是正解。
企業級訂單管理系統：
approveOrder()，客服僅可 viewOrder()，容器強制攔截此場景滿足準則 1-7 中 5 項以上，EJB 為正確選擇。
| 需求 | EJB 方案 | 現代輕量替代 (Spring 生態) | 選擇建議 |
|---|---|---|---|
| 分布式部署/遠程調用 | RMI/IIOP, Web Service | Spring Remoting (RMI/HttpInvoker), gRPC, Dubbo, Spring Cloud Feign | 微服務架構首選現代 RPC/REST |
| 聲明式事務 | CMT (Container Managed Transaction) | @Transactional + JTA (Atomikos/Bitronix) 或本地事務 | Spring 事務更靈活、輕量 |
| 方法級安全 | EJB Security Annotations | Spring Security @PreAuthorize, ACL | Spring Security 功能更豐富 |
| 持久化/ORM | CMP/BMP Entity Bean | JPA (Hibernate/EclipseLink) + Spring Data JPA | JPA 為行業標準，EJB Entity Bean 已淘汰 |
| 叢集/高可用 | 容器內建叢集 | K8s + Spring Cloud / Service Mesh | 雲原生時代容器編排為主流 |
EJB 曾是 J2EE 核心，但隨著 Spring 生態成熟、微服務興起、雲原生普及，其適用場景大幅收窄。七大準則為決策提供客觀框架：僅當系統真正需要分布式事務、細粒度安全、多客戶端共享、物理隔離、標準化戰略、高擴展性時，EJB 才是合理投資。對於絕大多數現代 Web 應用，POJO + Spring + JPA + 輕量 RPC 是更敏捷、高效、可維護的選擇。
