MVC 模式在 GUI 應用程式中的四大常見誤區

前言

MVC (Model-View-Controller) 是 GUI 架構基石，但實務中常被誤解。本文針對嵌入式/桌面平台 (如 MFC、Qt、GTK) 常見四大誤區說明。

誤區一：Controller 與 Model 混為一談

現象：以 Glade 為例，產生的 callbacks.c (事件處理) 被誤當作 Model，導致 Model 內含 UI 控制項指標。

正解：

• Controller：視窗事件處理函數 (如 OnButtonClick)，職責：① 將 UI 動作轉為 Model 操作 (如 model.DeleteRecord())；② 將 Model 變更更新至 View。
• Model：純業務邏輯與資料，**零 UI 相依性** (無控制項、視窗句柄、訊息迴路)。

Controller 與 View 耦合緊密 (同一視窗類別)，通常不分離；Model 必須與兩者解耦。

誤區二：所有 View 都綁定同一 Model

現象：獨立對話框 (如關於視窗、設定視窗) 強行掛載主 Model。

正解：獨立 UI 應以 **函式呼叫/參數傳遞** 與主邏輯互動，而非共享 Model。強行綁定會增加 Model 複雜度，降低 UI 復用性。

誤區三：一個應用程式只能有一個 Model

現象：將無關業務領域 (如通訊錄、行事曆、多媒體播放) 強行合併為單一 CApplicationModel。

正解：Model 是 **邏輯概念**，而非實體單例。互不相關的功能群應擁有獨立 Model (CContactModel, CCalendarModel...)，由各自 Controller 協調，主視窗僅組合呈現。

誤區四：Model 是不可再分的巨石類別

現象：所有非 UI 代碼 (資料庫存取、網路協議、演算法、序列化) 全塞進 CModel，動輒數萬行。

正解：Model 內部應進一步分層：

• Domain Model：核心業務實體與規則 (純 C++ 類別)。
• Data Access Layer：DAO/Repository 封裝 SQL/檔案 IO。
• Service Layer：協調多個 Domain Object 完成用例 (如 COrderService)。
• DTO/VO：跨層傳輸資料結構。

Controller 僅呼叫 Service Layer，不知 DAO 細節。Model 只是架構邊界的 **邏輯標籤**，不一定出現在類別名稱中。

總結

MVC 核心在於 **關注點分離**：Model 管資料與規則，View 管呈現，Controller 管協調。誤區本質皆為 **過度耦合** 或 **職責不清**。輕量級架構：Controller = 視窗類別，Model = 服務層 + 領域模型，View = 資源/佈局檔 + 繪圖代碼。