Java B/S 架構演進史：從 JSP+JDBC 到 MVC 框架的最佳實踐

階段一：JSP + JDBC —「頁面即邏輯」的混沌期

最原始模式：JSP 頁面混雜 HTML、Java 代碼 (<% %>)、JDBC 操作。

• 優點：上手極快、零配置、適合極小型專案。
• 致命缺點：
  1. 除錯困難：JSP 編譯後行號對不上、斷點難設。
  2. 維護噩夢：修改一個需求需改動 N 個頁面，Copy-Paste 代碼到處都是。
  3. 零重用：業務邏輯與顯示強耦合，無法單獨測試。
  4. 人員依賴：需資深開發者才能駕馭，新人上手極慢。

結論：現代專案完全棄用此模式。

階段二：JSP + JavaBean —「業務邏輯下沉」的初步分離

JSP 負責顯示與請求參數獲取，JavaBean 封裝業務邏輯與資料存取。

• 進步：JavaBean 可獨立單元測試、邏輯可重用。
• 殘留問題：
  1. JSP 仍需編寫「參數綁定 → 呼叫 Bean → 根據結果轉發」的控制代碼，大量重複。
  2. 控制邏輯分散在各 JSP，結構不清晰，修改流程需逐頁檢查。
  3. 轉發機制導致最終顯示頁面仍包含控制代碼，未真正達到「顯示/處理分離」。

適用場景：小型專案、快速原型。

階段三：MVC 框架時代 —「約定優於配置」的工程化

核心角色映射

演進路徑

1. JSP + Servlet + JavaBean：Servlet 做 Controller，但隨著 Bean/View 增加，Servlet 頻繁修改 (調用邏輯、轉發目標硬編碼)。
2. Front Controller + Application Controller (Command 模式)：FrontController 統一入口，ApplicationController (Command) 負責具體業務分派，單一職責原則落地。
3. Model 層解耦：Model 依賴 HttpServletRequest 難測試 → 拆分為 Action Layer (處理請求) + Domain Model (純 POJO) + Persistent Layer (DAO/Hibernate)。
4. 配置檔驅動：Action-View 映射移至 XML，變動只改配置、不動代碼、不重編譯 (Struts 核心思想)。
5. 圖形化配置工具：Page Flow 等視覺化工具生成配置，減少手寫 XML 錯誤。

主流 MVC 框架對比

• Struts 1.x：開山鼻祖，ActionForm/Action 設計，配置繁重，但生態成熟、文檔豐富。
• WebWork / Struts 2：攔截器鏈、OGNL 表達式、POJO Action，開發體驗優於 Struts 1。
• Spring MVC：@Controller/@RequestMapping 註解驅動、無侵入、與 Spring IOC/AOP 無縫整合，現代首選。

View 層純潔性建議

即使使用 MVC 框架，開發者常在 JSP 濫用 JSTL/Scriptlet 處理複雜邏輯。強烈建議：View 採用 Velocity / FreeMarker / Thymeleaf 等純模板引擎，強制禁止 Java 代碼進入視圖，確保「View 只負責 View」。

未來展望

• AJAX / 非同步交互：豐富客戶端體驗，Controller 回傳 JSON 而非 HTML。
• 組件化 Web 框架：Tapestry、JSF、Wicket，將 UI 封裝為可重用組件。
• Rich Internet Application：Flex、Laszlo (歷史)、現代則為 React/Vue/Angular + REST API。

總結

Java B/S 發展史，本質是「關注點分離」不斷深化的歷程：
Scriptlet 混雜 → JavaBean 封裝邏輯 → MVC 分離控制/顯示 → Front Controller 統一入口 → 配置驅動解耦 → 純模板 View → 前後端分離。
每一步都在降低耦合、提高內聚、強化可測試性。理解這條主線，技術選型就不會迷失。