J2EE 開發框架演進史：從 Struts、Hibernate 到 Spring 的範式轉移

前言：標準平台與開發實踐的張力

J2EE 為中介軟體領域建立了統一標準（分散式事務、目錄服務、訊息服務、JDBC 等），卻始終未能提供令人滿意的應用程式編程模型。Sun 與應用伺服器廠商試圖以工具降低複雜度，但工具生成的代碼往往與框架本身同樣複雜，且遠遜於 .NET 生態的工具鏈。這迫使開源社區另闢蹊徑——以框架簡化 J2EE 開發，Struts、Hibernate、Spring 遂成為那個時代的三駕馬車。

為何需要框架？好萊塢原則的實踐

框架本質是「半成品應用」：它調用你的代碼（好萊塢原則：「別調用我們，我們會調用你」），管理程式流程，而非像類庫般被動被調用。優秀框架帶來的價值：

• 開發者只寫必要代碼，隔離底層 API
• 強制清晰架構，提升內聚性，降低新人上手門檻
• 內建最佳實踐，透過文檔範例傳遞
• 代碼更易測試、更穩健（經大規模生產驗證）

第一波浪潮：Struts 與 Web MVC 的標準化

背景：JSP Model 1 的崩潰

1999-2000 年，開發者發現 JSP Model 1 將請求處理、業務邏輯、HTML 模板糅雜在一起，維護極其困難。缺乏標準框架下，大家自行實作 Front Controller 模式，質量參差不齊。

Struts 的歷史地位

2001-2002 年 Apache Struts 發布，雖非完美，卻以「足夠好」確立了事實標準。它讓 MVC 在 Web 層落地：

• ActionServlet 作為前端控制器
• ActionForm 封裝表單數據
• Action 協調業務邏輯
• JSP 專注視圖渲染

Struts 幾乎滲透進每個 J2EE 專案，甚至保守組織也接受其 Apache 許可，成為 J2EE 架構的事實組件。

第二波浪潮：Hibernate 終結持久化迷途

JDBC 與 Entity Bean 的雙重失敗

• JDBC：強迫開發者用 Java 代碼處理關係模型，阻抗失配嚴重
• Entity Bean：笨重、關聯支援缺失、測試困難、EJB-QL 糟糕，即便 EJB 2.0/2.1 改進仍鮮少採用

ORM 的破局之路

早期商業 ORM（TopLink）昂貴且違背 EJB 標準；JDO 雖標準化但廠商冷遇。真正的轉折點在 2002 年：

1. Entity Bean 實踐徹底失敗，開發者拋棄規範
2. Hibernate 橫空出世：首個功能完備、API 直觀、專職團隊維護的開源 ORM

Hibernate 雖非理論創新，但以「更易用、更直接、更廉價」的編程模型贏得市場。隨後 TopLink 開放授權、商業 JDO 實現湧現，ORM 徹底贏得持久化戰場。

第三波浪潮：Spring 統合分層架構的膠水

核心痛點：框架整合與業務邏輯的鴻溝

Struts + Hibernate 解決了 Web 層與持久層，但業務邏輯層仍無合適模型。EJB 雖提供方案，卻繼承了沉重的編程模型。

Spring 的革命性組合：IoC + AOP

• IoC（控制反轉）：容器管理物件生命週期與依賴關係，將 POJO 從 J2EE 環境解耦
• AOP（面向切面）：橫切關注點（事務、安全、日誌）模組化，無侵入式增強 POJO
• 服務抽象：聲明式事務支援所有 POJO，提供除 EJB 外的完整企業級服務選項

輕量級容器的測試驅動優勢

Spring、PicoContainer、HiveMind 等輕量容器將 POJO 脫離 J2EE API，使單元測試變得極簡——無需部署伺服器、無需模擬容器。這直接催化了 TDD（測試驅動開發）在企業級開發的普及。

未來展望：開源創新與標準化的博弈

兩大戰場的衝突

AOP 的崛起與 JCP 的遲疑

Spring/dynaop 等「帶拐杖的 AOP」普及了切面概念，AspectJ 等純粹 AOP 技術正崛起。JBoss 透過 JCP 推動 EJB 3.0 整合 AOP，但 JCP 尚未正式擁抱 AOP 標準化。

結語：回歸 POJO 程式設計的本質

下一代 J2EE 規範必將擁抱 Spring/Hibernate 證明的簡單 POJO 模型。開發者將從「被規格綁架」轉向「以經驗驅動開發」。這場變革不似過往規格發布後的空歡喜，而是實實在在的生產力解放——因為它源自無數專案的血淚驗證，而非象牙塔的想像。