公司有一套已運行多年的內部管理系統，原本是 Windows Forms 應用程式，現在決定整個搬到 Web 平台；新系統起初以 ASP.NET MVC + Razor Page 為主架構，同時也有部分功能採用 Web API 的形式，形成了一種混搭的局面；這讓我開始思考這兩種做法的本質差異是什麼？在什麼情況下應該選哪一種？在討論這個問題之前，得先把 MVC 架構弄清楚。

MVC 是什麼？

MVC 是一種將應用程式切分成三個層次的架構模式：

  • Model：應用程式的核心，負責管理資料、業務規則與邏輯，獨立於使用者介面
  • View：資料的視覺呈現，在 ASP.NET 中就是 Razor Page（.cshtml）
  • Controller：中間協調者，接收使用者輸入、呼叫 Model 處理、再選擇適合的 View 回應

這三層緊密協作，最關鍵的特點是：整個渲染過程發生在伺服器端，瀏覽器只負責顯示已經組好的 HTML。

瀏覽器 ──請求──▶ Controller ──呼叫──▶ Model（業務邏輯 + 資料存取）
                    │                        │
                    │                        ▼
                    │                 DB / Repository
                    │                        │
                    │◀────── 資料 ───────────┘
                    │
                    ▼ 傳遞資料
                  View（Razor Page）
                    │
瀏覽器 ◀──完整 HTML──┘

用 ASP.NET Core MVC 來說明

一個典型的 MVC 流程如下：

Controller：呼叫 Model 取得資料、選擇 View

 1public class ProductController : Controller
 2{
 3    private readonly AppDbContext _db;
 4    public ProductController(AppDbContext db) => _db = db;
 5
 6    public IActionResult Index()
 7    {
 8        // 1. 從 Model 層取得資料
 9        var products = _db.Products.ToList();
10
11        // 2. 把資料傳給 View 渲染
12        return View(products);
13    }
14}

View：接收 Model 傳來的資料，產生 HTML

1@model List<Product>
2
3@foreach (var p in Model)
4{
5    <div class="product-card">
6        <span>@p.Name</span>
7        <span>$@p.Price</span>
8    </div>
9}

整個流程發生在後端，瀏覽器收到的是已經填好資料的完整 HTML 頁面。

MVC 的優點

架構直觀，上手快

整個專案在同一個 Codebase 裡，資料流向清楚：Request 進來 → Controller 處理 → Model 取資料 → View 渲染 → HTML 回傳，對剛接觸 Web 開發的人來說，這條線很好追蹤。

首次載入速度快

瀏覽器收到 HTML 即可開始渲染，不需要先下載 JavaScript bundle、再打 API 取資料、再渲染畫面這三個步驟，對網路環境不穩定的使用者來說體驗差異特別明顯。

狀態管理簡單

Session、Cookie、身份驗證由後端統一管理，不需要在前端額外維護。

安全邊界清楚

敏感的商業邏輯和資料處理都在後端，不需要擔心敏感資料被暴露在前端程式碼或網路請求中。

MVC 的缺點

前後端高度耦合

Controller 知道有哪些 View 存在，View 又直接依賴 Model 的資料結構，這種相互依賴使得修改任何一層都可能波及其他層。

1// 改了 Model 的資料結構
2// → View 的顯示邏輯可能要跟著改
3// → Controller 的取資料邏輯可能也要調整
4// 牽一髮動全身
5return View("ProductList", products);

互動體驗受限

傳統 MVC 的每次操作，預設都會觸發整頁重新載入（Full Page Reload），對於需要即時回饋的互動如表單驗證、動態搜尋、拖拉排序等，體驗相對較差；雖然可以加入 AJAX 來局部更新，但這本質上是在 MVC 上補丁而非根本解法。

難以支援多端

同一套商業邏輯，如果要同時服務網頁、iOS App、Android App，MVC 就顯得力不從心，因為它只能吐出 HTML，而 App 需要的是資料（JSON）。

大型團隊協作困難

前端工程師和後端工程師可能需要修改同一個 Controller 或同一份 View 檔案，容易產生衝突，也難以真正平行開發。

測試邊界模糊

當 Controller 裡夾雜了太多商業邏輯，測試時必須連同 View 渲染邏輯一起考慮，單元測試的邊界就變得不清晰。

MVC 適合什麼情境？

綜合以上來說，MVC 並非過時的技術，它在特定情境下仍然是務實的選擇：

  • 適合：
    • 內部管理系統（使用者固定）
    • 小型全端團隊
    • 以表單和報表為主的功能
  • 不適合：
    • 需要支援 App 或第三方 API
    • 需要高度互動的 SPA 體驗
    • 大型前後端分工的團隊
    • 需要即時更新的動態功能

以我們的 WinForms 遷移專案來說，MVC 其實相當符合需求：使用者是固定的內部員工、畫面以表單和清單為主、當下沒有多端需求，這些特性都算是 MVC 的適用範圍。

MVC 是一個設計思路清晰、適合特定場景的架構，但它並非萬能；當應用程式的需求超出它的適用範圍，例如需要支援多端、需要複雜互動、需要大型團隊分工等，就需要考慮別的方向；下一篇我們將探討另一個方向：前後端分離架構。