2000 年前,EJB 滿懷傳奇色彩被企業擁抱;數年後,卻陷入懷疑與猶豫:系統更複雜、成本更高、不如消息傳遞互操作、跨平台成空談。.NET 後發優勢凸顯,Java 陣營內部攻擊聲浪高漲。但技術不應成明星被捧殺,亦無輕易倒下的軟體技術。EJB 困境多源於錯誤濫用,而非技術本身失效。本文從設計初衷、商業環境、技術瓶頸三維度重新審視。
核心洞見:脫離設計目標談價值失去意義。必須在商業環境與技術瓶頸中重新審視。
在分布式事務、強一致性、高可用、跨語言/平台互操作、複雜業務邏輯封裝等 EJB 擅長領域,至今難尋更強競爭者。
| 維度 | EJB 2.x 痛點 | EJB 3.x / Java EE / Spring 回應 |
|---|---|---|
| 複雜度 | 大量接口、描述符、樣板代碼 | POJO + 註解、依賴注入、約定優於配置 |
| 重用粒度 | 粗粒度遠程組件,網絡開銷大 | 細粒度本地 Bean + 遠程門面,按需分布 |
| 測試性 | 需容器難單元測試 | POJO 可脫容器測試,Arquillian 整合測試 |
| 生態 | 封閉、廠商綁定 | 開放標準、Spring 生態、MicroProfile |
EJB 的歷史辯證告訴我們:沒有失敗的技術,只有錯位的應用。組件化思想永不落伍,EJB 只是某個時代的具體載體。今天我們用 Spring Boot 構建微服務、用 gRPC 實現跨語言調用、用 Kubernetes 編排容器,本質上仍在追求 EJB 當年許下的承諾——可重用、可移植、可管理、可擴展的企業級組件模型。理性選型,放對位置,技術才會發光。