MVC 模式在 Java Web 應用中的演進與實踐：從經典 Smalltalk 到 Struts、Spring MVC 的架構抉擇

MVC 起源與核心職責

Java Web MVC 歷代演進

1. Model 1 (JSP 獨大)：JSP 內嵌 Java 程式碼、JDBC 直連資料庫 → 混亂、難維護。
2. Model 2 (Servlet + JSP)：Servlet 做 Controller，JSP 做 View → 關注點分離雛形。
3. Struts 1：ActionForm + Action + struts-config.xml → 確立 MVC 框架標準，但配置繁重、ActionForm 綁定死板。
4. Spring MVC：POJO Controller、Annotation 配置、強大綁定/驗證/攔截器、REST 原生支援 → 現代主流選擇。
5. 前後端分離 (SPA)：Controller 變為 REST API，View 移至瀏覽器 → MVC 變形為「後端 MVC + 前端 MVVM」。

常見誤區釐清

「View 不能有 Java 程式碼」 — 錯誤。JSP 作為 View 技術，使用 JSTL/EL 表達式存取 Model 資料是標準做法。關鍵在於：View 只負責呈現，不包含業務邏輯、資料庫存取、複雜演算法。

「Struts = MVC 全部」 — 錯誤。Struts 僅是 Presentation 層的 Front Controller。Business Delegate、Service、DAO 屬於 Business/Integration 層，不在 Struts 職責內。

View Helper 模式：解決複雜呈現邏輯

當 JSP/模板需處理格式化、條件渲染、集合轉換等複雜邏輯時，引入 View Helper (TagLib、EL Function、Helper Bean) 封裝呈現邏輯，保持模板乾淨。

三層架構 vs. MVC：正確關係

+--------------------------+
|      Presentation        |  ← MVC 在這裡
|  (Controller + View)     |
+--------------------------+
|       Business           |  ← Service, Domain Model
+--------------------------+
|      Integration         |  ← DAO, Repository, External API
+--------------------------+

先做三層架構設計（整合層、業務層介面），再決定 Presentation 如何與 Business 互動，才是專案成功關鍵。

現代選型建議

總結

MVC 不是框架，是架構模式。理解其核心——關注點分離、單一職責、依賴反轉——比記住某個框架的 XML 配置更有價值。無論技術棧如何演進，這三大原則永遠是優秀 Java Web 架構的基石。