Day 24：模型-视图-控制器（Model-View-Controller, MVC）

一句话定义：MVC（Model-View-Controller）把应用程序切成三块互相分离的职责——Model 负责数据与业务规则，View 负责把数据画到屏幕上，Controller 负责接收用户输入并决定调用 Model 的哪个行为、让 View 如何更新。

它是 1979 年 Trygve Reenskaug 在 Xerox PARC 为 Smalltalk-80 提出的架构思想，也是现代几乎所有 GUI 框架（包括 Qt 的 Model/View）的地基。今天这篇不是再讲一个"类怎么写"，而是讲一次架构级的职责切分：当你从"写页面"升级到"设计客户端架构"时，MVC 是你第一个必须想清楚的东西。

先看反例。这是一个"能跑，但三个月后没人敢改"的 Qt 窗口类——数据、界面、业务逻辑、持久化全部挤在一个类里：

class TaskWindow : public QWidget {
    Q_OBJECT
public:
    TaskWindow(QWidget* parent = nullptr) : QWidget(parent) {
        auto* layout = new QVBoxLayout(this);
        list_   = new QListWidget(this);
        input_  = new QLineEdit(this);
        button_ = new QPushButton("添加", this);
        layout->addWidget(list_);
        layout->addWidget(input_);
        layout->addWidget(button_);

        // 事件处理、业务规则、数据存储、界面刷新全部混在这里
        connect(button_, &QPushButton::clicked, this, [this] {
            const QString text = input_->text().trimmed();
            if (text.isEmpty()) return;                 // 校验规则
            if (text.size() > 50) {                     // 业务规则
                QMessageBox::warning(this, "错误", "标题过长");
                return;
            }
            tasks_.push_back({text, false});            // 数据存储
            QSqlQuery q;                                // 又是持久化
            q.prepare("INSERT INTO tasks(title) VALUES(?)");
            q.addBindValue(text);
            q.exec();
            QListWidgetItem* item = new QListWidgetItem(text);  // 界面刷新
            item->setFlags(item->flags() | Qt::ItemIsUserCheckable);
            item->setCheckState(Qt::Unchecked);
            list_->addItem(item);
            input_->clear();
            statusBar_->showMessage(QString("共 %1 条").arg(tasks_.size()));
        });
    }
private:
    QListWidget* list_;
    QLineEdit*   input_;
    QPushButton* button_;
    std::vector<Task> tasks_;
};

它的问题在哪？

• 违反 SRP（单一职责原则）：这个类有 5 个变化的理由——校验规则改了、数据库换了、界面换成 QTableView、加了批量导入、要支持 Undo。任何一个理由都会让同一个文件中枪，而且改 A 的时候随时可能碰坏 B。
• 违反 OCP（开闭原则）：想做一个"命令行版本"或"无界面单元测试"，你会发现业务规则被死死焊在 QMessageBox、QListWidgetItem 上，只能靠复制粘贴改一份，然后两份逻辑开始各自腐烂。
• 违反 DIP（依赖倒置原则）：高层业务规则直接 new 了低层界面控件和 QSqlQuery。依赖方向全是从"策略"指向"细节"，方向反了。
• 不可测试：想验证"标题超过 50 字必须拒绝"，你必须先起一个 GUI、模拟点击、还得连上数据库。测试从 5 毫秒的断言变成 5 秒的集成测试。
• 无法复用：同一份"任务逻辑"在桌面端、Web 端、命令行三处要用，只能写三遍。

MVC 就是对这一坨的正面回答：把"数据长什么样/怎么变"、"屏幕上长什么样"、"用户的动作翻译成什么操作"三件事，物理地拆到三个对象里去。

通俗解释：把界面程序想象成一家餐厅。

• Model（厨房 + 仓库）：真正做饭、记账、管理食材库存的地方。它只关心"菜怎么做、账怎么算"，完全不关心客人是坐在大厅还是包厢、菜单是纸质还是平板。仓库里食材变了，它自己有义务通知外面一声。
• View（菜单 + 摆盘）：客人看到的全部样子——菜单的价格字号、盘子怎么摆。它不知道菜是怎么炒出来的，只负责把厨房给的成品端上来展示。菜单换一张，厨房不用重训厨师。
• Controller（服务员）：客人说"来份宫保鸡丁"，服务员把这句话翻译成"下单：宫保鸡丁 × 1"递给厨房，再把厨房的反馈传达给客人。他不炒菜、不摆盘，只做翻译和调度。

关键点在于：三者之间只通过"稳定的接口"对话，而不是互相伸手进去改对方的内存。

数据流一句话概括：

为什么"共同真理源"如此重要？因为一旦同一份数据同时存在两处（比如上面反例里的 tasks_ 和 QListWidget 里的条目），就必然出现"不同步"的 bug——删除时忘了删一边、排序后顺序错位、Undo 后对不上。MVC 用一句话消掉了整类 bug：数据只有一个权威副本，界面是它的投影。

          ┌──────────────────────────────────────────────┐
          │                  用户输入                     │
          └───────────────────────┬──────────────────────┘
                                  │ 事件 / 动作
                                  ▼
   ┌────────────────────────┐          ┌──────────────────────────┐
   │      Controller        │          │          View            │
   │  输入翻译 + 调度        │          │  渲染 + 转发用户意图      │
   └───────────┬────────────┘          └────────────▲─────────────┘
               │  ① 调用 Model 的行为                │ ③ 通知变化后重新渲染
               │     (setValue / addTask ...)        │   (读取 data 拉取)
               ▼                                     │
   ┌───────────────────────────────────────────────────────────────┐
   │                          Model                                │
   │  数据 + 业务规则 + 状态通知（Observer / signal）                 │
   │  ✦ 不引用任何 View / Controller 的具体类型（只暴露抽象接口）      │
   └───────────────────────────────────────────────────────────────┘
               │  ② 状态变化 → 广播通知（不含任何界面细节）
               └──────────────────────────────►  View / Controller 订阅

角色	核心职责	允许知道什么	绝对不能知道什么
Model	持有数据、实现业务规则（校验/计算/持久化）、状态变化时发出通知	自己的数据结构、业务不变量、通用的通知机制（信号/观察者列表）	任何按钮、窗口、颜色、字体；任何具体 View 类名
View	把 Model 或 ViewModel 的数据渲染成像素；把原始用户事件转成"语义意图"	Model 的只读接口 / 通知信号；自己的控件	业务规则的实现细节（不该写 if (title.size() > 50)）
Controller	把 View 的意图翻译成对 Model 的调用序列；决定"下一步给用户看什么"	Model 的写接口、View 的回调接口	控件内部布局细节；数据的具体存储格式

依赖方向（这是最容易做错的一点）：Controller 依赖 Model 和 View（它要调度两者）；Model 不依赖任何人（它是被依赖方，只通过抽象的"通知"向外广播）；View 依赖 Model 的只读接口。整条依赖链必须指向稳定的一端（Model），而不是指向易变的界面。很多"伪 MVC"失败的原因，就是 Model 里偷偷 #include <QMessageBox>——那一刻分层就崩了。

下面是一个不依赖任何 GUI 框架的完整 MVC，用 std::function 做通知通道。它只有 80 行，但三层职责清晰可见。请重点体会：Model 里没有一行是给界面写代码。

// mvc_min.cpp  —  g++ -std=c++17 -Wall mvc_min.cpp -o mvc_min
#include <iostream>
#include <functional>
#include <string>
#include <vector>
#include <stdexcept>

// ================= Model：数据 + 业务规则 + 变更通知 =================
class CounterModel {
public:
    using Observer = std::function<void(int)>;   // 只传"值"，不传任何界面类型

    void addObserver(Observer obs) { observers_.push_back(std::move(obs)); }

    // 业务动作：唯一合法的改状态入口
    void increment() { setValue(value_ + 1); }
    void decrement() { setValue(value_ - 1); }

    int value() const noexcept { return value_; }

private:
    void setValue(int v) {
        if (v == value_) return;          // 幂等：值没变就不通知，避免无谓刷新
        value_ = v;
        notify();
    }
    void notify() {
        for (const auto& obs : observers_) obs(value_);   // 广播，与界面无关
    }

    int value_{0};
    std::vector<Observer> observers_;
};

// ================= View：只负责渲染 + 暴露"用户意图"回调 =================
class ConsoleView {
public:
    // 视图对外暴露的语义意图（由 Controller 注入实现）
    std::function<void()> onIncrement;
    std::function<void()> onDecrement;

    void render(int value) const {                     // 纯渲染，无业务逻辑
        std::cout << "[View] 当前计数 = " << value << '\n';
    }

    // 模拟"用户点了按钮"，把控件事件翻译成语义意图后交给外面
    void simulateClick(const std::string& btn) const {
        if (btn == "+" && onIncrement)      onIncrement();
        else if (btn == "-" && onDecrement) onDecrement();
    }
};

// ================= Controller：把 View 的意图接到 Model 的行为上 =================
class CounterController {
public:
    CounterController(CounterModel& model, ConsoleView& view)
        : model_(model), view_(view) {
        // ① Model -> View：状态变了就重新渲染
        model_.addObserver([this](int v) { view_.render(v); });
        // ② View -> Model：用户意图转发成模型行为
        view_.onIncrement = [this] { model_.increment(); };
        view_.onDecrement = [this] { model_.decrement(); };
    }

private:
    CounterModel& model_;   // 用引用表达"不拥有、只管调度"
    ConsoleView&  view_;
};

int main() {
    CounterModel     model;
    ConsoleView      view;
    CounterController controller(model, view);   // 接线（Wiring）

    view.render(model.value());       // 首次渲染初值
    view.simulateClick("+");          // 用户点击 "+"
    view.simulateClick("+");          // 再次点击 "+"
    view.simulateClick("-");          // 点击 "-"
    return 0;
}

程序实际输出：

[View] 当前计数 = 0
[View] 当前计数 = 1
[View] 当前计数 = 2
[View] 当前计数 = 1

这段代码做对了什么？①CounterModel 可以单独写单元测试，断言 increment() 两次后 value()==2，完全不需要界面；②换一个 QtView 或 WebView，Model 一行不改；③setValue 里的幂等判断把"值没变不刷新"这条性能规则收在 Model 内，任何 View 都自动受益，不会漏；④所有改状态的路径都必须经过 setValue，通知永不遗漏——这是 MVC 能"自动同步"的根本原因。

Qt 官方文档《Model/View Programming》里明确写道：Qt 的 Model/View 架构是经典 MVC 的一个变体——Qt 把 View 与 Controller 合并了（View 自己处理输入），并引入 Delegate（委托）来接管"如何绘制单个单元格 + 如何为单元格提供编辑器"。所以你在 Qt 里写 MVC，实际是写"Model + View(含输入) + Controller(调度)"。

下面用一个任务清单演示：TaskModel 是纯数据，TaskController 是调度层，QListView/QLineEdit 是视图。

文件 1：taskmodel.h（Model——注意它完全没有引用任何 View）

#pragma once
#include <QAbstractListModel>
#include <QString>
#include <QByteArray>
#include <vector>

// Model：只负责数据与业务规则，不认识任何 View
class TaskModel : public QAbstractListModel {
    Q_OBJECT
public:
    enum Roles { TitleRole = Qt::UserRole + 1, DoneRole };

    explicit TaskModel(QObject* parent = nullptr);

    // ---- QAbstractItemModel 必填的三个纯虚/关键接口 ----
    int rowCount(const QModelIndex& parent = QModelIndex()) const override;
    QVariant data(const QModelIndex& index, int role = Qt::DisplayRole) const override;
    QHash<int, QByteArray> roleNames() const override;

    // ---- 业务动作（供 Controller 调用）----
    void addTask(const QString& title);
    void toggleDone(int row);
    void removeTask(int row);
    int  count() const { return static_cast<int>(tasks_.size()); }

private:
    struct Task { QString title; bool done; };
    std::vector<Task> tasks_;
};

文件 2：taskmodel.cpp（注意每个改动都用 begin/end 配对包裹，这是 Qt 通知 View 刷新的协议）

#include "taskmodel.h"

TaskModel::TaskModel(QObject* parent) : QAbstractListModel(parent) {
    tasks_ = { {"学习 MVC 分层", false}, {"写 Qt Model/View 示例", true} };
}

int TaskModel::rowCount(const QModelIndex& parent) const {
    if (parent.isValid()) return 0;            // 列表模型：只有顶层有行
    return static_cast<int>(tasks_.size());
}

QVariant TaskModel::data(const QModelIndex& index, int role) const {
    if (!index.isValid() || index.row() >= rowCount()) return {};
    const Task& t = tasks_[index.row()];
    switch (role) {
    case Qt::DisplayRole:
    case TitleRole:  return t.title;
    case Qt::CheckStateRole:
    case DoneRole:   return t.done ? Qt::Checked : Qt::Unchecked;
    default:         return {};
    }
}

QHash<int, QByteArray> TaskModel::roleNames() const {
    return { {TitleRole, "title"}, {DoneRole, "done"} };   // 方便 QML / Delegate 使用
}

void TaskModel::addTask(const QString& title) {
    const QString t = title.trimmed();
    if (t.isEmpty() || t.size() > 50) return;   // 业务校验收在 Model，界面无从绕过
    const int row = rowCount();
    beginInsertRows(QModelIndex(), row, row);   // ① 通知 View "我要插入了"
    tasks_.push_back({t, false});
    endInsertRows();                            // ② View 自动请求新行数据并刷新
}

void TaskModel::toggleDone(int row) {
    if (row < 0 || row >= rowCount()) return;
    tasks_[row].done = !tasks_[row].done;
    const QModelIndex idx = index(row, 0);
    emit dataChanged(idx, idx, {DoneRole, Qt::CheckStateRole});  // 只刷新这一行
}

void TaskModel::removeTask(int row) {
    if (row < 0 || row >= rowCount()) return;
    beginRemoveRows(QModelIndex(), row, row);
    tasks_.erase(tasks_.begin() + row);
    endRemoveRows();
}

文件 3：taskcontroller.h / taskcontroller.cpp（Controller——唯一同时认识 Model 和 View 的地方）

// ---------- taskcontroller.h ----------
#pragma once
#include <QObject>
#include <QModelIndex>

class TaskModel;
class QLineEdit;
class QListView;

// Controller：把视图事件翻译成 Model 行为；同时负责"跨层协调"
class TaskController : public QObject {
    Q_OBJECT
public:
    TaskController(TaskModel* model, QLineEdit* input, QListView* view,
                   QObject* parent = nullptr);

public slots:
    void submitNewTask();               // 用户在输入框按回车
    void handleDoubleClicked(const QModelIndex& index);  // 双击切换完成
    void handleDeleteRequested();       // 删除当前选中项

private:
    TaskModel* model_;                  // 借用指针，不拥有
    QLineEdit* input_;
    QListView* view_;
};

// ---------- taskcontroller.cpp ----------
#include "taskcontroller.h"
#include "taskmodel.h"
#include <QLineEdit>
#include <QListView>
#include <QItemSelectionModel>

TaskController::TaskController(TaskModel* model, QLineEdit* input,
                               QListView* view, QObject* parent)
    : QObject(parent), model_(model), input_(input), view_(view) {
    // View 事件 -> Controller 槽（这就是 MVC 里 "View 把意图交给 Controller"）
    connect(input_, &QLineEdit::returnPressed, this, &TaskController::submitNewTask);
    connect(view_,  &QListView::doubleClicked, this, &TaskController::handleDoubleClicked);
}

void TaskController::submitNewTask() {
    const QString text = input_->text();
    if (text.trimmed().isEmpty()) return;
    model_->addTask(text);        // 只和 Model 打交道
    input_->clear();             // 视图清理属于"交互反馈"，可由 Controller 决定
}

void TaskController::handleDoubleClicked(const QModelIndex& index) {
    if (index.isValid()) model_->toggleDone(index.row());
}

void TaskController::handleDeleteRequested() {
    const QModelIndex cur = view_->currentIndex();
    if (cur.isValid()) model_->removeTask(cur.row());
}

文件 4：main.cpp（组装与接线，main 是唯一知道"三层怎么拼起来"的地方）

#include <QApplication>
#include <QWidget>
#include <QVBoxLayout>
#include <QHBoxLayout>
#include <QListView>
#include <QLineEdit>
#include <QPushButton>
#include "taskmodel.h"
#include "taskcontroller.h"

int main(int argc, char* argv[]) {
    QApplication app(argc, argv);

    TaskModel model;                                  // ---- Model ----
    QWidget window;
    window.setWindowTitle("Day 24 · Qt MVC 演示");
    auto* root   = new QVBoxLayout(&window);
    auto* view   = new QListView(&window);            // ---- View（显示）----
    auto* input  = new QLineEdit(&window);            // ---- View（输入）----
    auto* delBtn = new QPushButton("删除选中", &window);
    auto* row    = new QHBoxLayout;
    row->addWidget(input);
    row->addWidget(delBtn);
    input->setPlaceholderText("输入任务后回车…");
    root->addWidget(view);
    root->addLayout(row);

    view->setModel(&model);                           // View 绑定 Model（Qt 的关键一步）

    TaskController controller(&model, input, view, &window);  // ---- Controller ----
    QObject::connect(delBtn, &QPushButton::clicked,
                     &controller, &TaskController::handleDeleteRequested);

    window.resize(360, 460);
    window.show();
    return app.exec();
}

文件 5：CMakeLists.txt

cmake_minimum_required(VERSION 3.16)
project(Day24QtMvc LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_AUTOMOC ON)          # 自动为含 Q_OBJECT 的类生成 moc 代码

find_package(Qt6 REQUIRED COMPONENTS Widgets)

add_executable(Day24QtMvc
    main.cpp
    taskmodel.cpp
    taskcontroller.cpp
)
target_link_libraries(Day24QtMvc PRIVATE Qt6::Widgets)

构建与运行：cmake -B build -DCMAKE_PREFIX_PATH=/path/to/Qt/6.x/gcc_64 && cmake --build build && ./build/Day24QtMvc。你会看到：输入框回车后列表自动多一行；双击某行其复选框自动切换；删除按钮移除选中行。注意全程没有任何一行代码去 list->addItem() 或手动重建列表——View 是 Model 的自动投影，这就是 Qt Model/View 替 MVC 省掉的最大的活。

以"用户在输入框敲字后按回车，列表出现新任务"这条主线，逐帧拆解：

1. ① 接线阶段（main）：view->setModel(&model) 让 View 订阅 Model 的数据通知；TaskController 构造函数里把 QLineEdit::returnPressed 连到 submitNewTask()。此时三方互不认识对方内部，只持有接口级别的引用。
2. ② View 捕获输入：QLineEdit 收到回车键，发出 returnPressed 信号。View 不做任何业务判断——它既不知道 50 字上限，也不知道数据存在哪，它只负责"报告一个语义意图：用户提交了"。
3. ③ Controller 调度：TaskController::submitNewTask() 被调用。它做三件事：读取输入框文本、判断空串直接返回、调用 model_->addTask(text)、然后 input_->clear()。请注意：Controller 是唯一"跨层"的角色，它既碰 View 又碰 Model。
4. ④ Model 改状态 + 广播：addTask() 先做业务校验（trim、长度 ≤ 50），然后 beginInsertRows() 宣布"我将在第 row 行插入"，修改 tasks_，再 endInsertRows() 广播。此刻 Model 完全不知道有一个 QListView 存在。
5. ⑤ View 自动重绘：endInsertRows() 内部触发 rowsInserted 信号，QListView 收到后回调 rowCount() 与 data() 拉取新行内容并绘制，必要时重新计算滚动条。整个过程零手工刷新代码。

反方向（双击切换完成状态）同理：QListView::doubleClicked → TaskController::handleDoubleClicked(index) → model->toggleDone(index.row()) → emit dataChanged(idx, idx, {DoneRole}) → 只有那一行重绘。注意 toggleDone 里"翻转"这个业务动作由 Model 完成，Controller 只负责把"双击"翻译成"对第 N 行做翻转"，它不亲自改 bool。

把 MVC 拆开看，它其实同时回答了六个工程问题，每一个都对应一条设计原则：

• 解耦点（Decoupling）：Model 与 View 之间只保留"数据 + 变更信号"这一条通道。业务规则的改动不会穿透到界面代码，界面的重构（QListWidget → QTableView）也不会碰到业务规则。有没有解耦，可以用一个简单测试验证：把 Model 单独链接进一个没有 Qt Widgets 的控制台程序，能不能跑？能跑就是真解耦。
• 扩展点（Extension）：新增一个视图（表格视图、导出 CSV 的视图、QML 视图）只需要新增一个订阅者，零修改既有代码。这正是 OCP 的教科书形态——"对扩展开放，对修改关闭"。反例里那种写法每加一个视图就要改主类，是典型的"修改式扩展"。
• OCP（开闭原则）：Model 提供稳定的抽象接口（value()/data()/rowCount() + 通知），新行为通过"新增 View/Controller"落地，而不是"修改 if-else"。
• DIP（依赖倒置原则）：Controller 依赖的是 Model 的行为接口，View 依赖 Model 的只读接口——高层策略没有依赖低层细节。在 Qt 里 QAbstractItemModel 就是那个"抽象"，QListView 依赖它而不是依赖你的 TaskModel 具体类，所以你的任何模型都能塞给同一个视图。
• 组合优于继承：MVC 的三件套之间全是组合 + 委托（Controller 持有 Model& 和 View&，ViewModel 组合 View 的组合），没有一个 class TaskWindow : public TaskModel 这种"把数据和界面揉进一条继承链"的写法。继承会让"既是数据又是界面"绑死，组合让它们可以各自演化。
• 可测试性（Testability）：这是 MVC 最被低估的收益。Model 是纯逻辑，测试它不需要 GUI：TEST(TaskModelTest, RejectTooLongTitle) 直接断言 rowCount() 不变即可，毫秒级、无外部依赖。Controller 也可以用假的 View（一个只记录"被调了几次渲染"的 stub）来测。没有分层，这两类测试根本写不出来。

不用 MVC（或任何分层），代码不会立刻崩，而是以三种可预期的形态腐烂：

• if-else 膨胀：因为"谁能改数据"没有收口，每个事件处理器都自己写一遍校验。今天加一条"标题不能为纯数字"，就得在"新建""导入""粘贴""右键重命名"四个地方各补一个 if。漏掉一个就产生不一致——这类 bug 极难发现，因为多数路径是对的。
• 类膨胀（God Object）：反例那个 TaskWindow 从 200 行长到 2000 行：数据成员、槽函数、SQL、导出逻辑、国际化字符串全在一起。它成了所有人都要改、但没人敢大改的"上帝类"。代码评审时三行改动要读两个小时，团队速度被这个类拖着走。
• 耦合导致的连锁修改：产品说"任务列表要换成三栏看板"。在耦合写法里，你得改数据结构、改刷新逻辑、改右键菜单、改排序，而且每一处都得重新测一遍——因为你改了 5 个地方。在 MVC 里，这最多是换一个 View，Model 一行不动，回归测试范围缩小到"新 View 渲染对不对"。
• 测试成本失控：业务规则无法独立验证，只能靠"跑起来点一遍"。CI 里跑不了 GUI，于是质量全靠人工回归。久而久之，没人敢重构，技术债只增不减。
• 平台锁死：业务逻辑与 Qt Widgets 深度耦合后，想抽出核心逻辑做命令行工具、做服务端复算、做跨平台共享库（例如给 QML 前端和 Widgets 前端共用），成本接近重写。

更隐蔽的第四种腐烂："伪 MVC"。有人把类拆成了三个文件，但 Model 里 #include <QMessageBox> 弹窗、View 里写 if (text.length() > 50) 校验、Controller 里缓存了一份 QVector<Task> 副本。文件分开了，职责没分开——这比不拆更危险，因为它让人误以为架构已经理清。

✅ 适合的场景：

• 有"同一份数据、多个视图"的需求：比如同一个任务列表既要显示在主界面，又要显示在托盘悬浮窗、还要导出报表。MVC 让一份 Model 支撑多个 View，且自动同步。
• 交互逻辑较复杂、状态较多：编辑器、IDE、CAD、数据看板这类有大量"输入 → 状态机 → 界面反映"循环的应用。把交互调度独立成 Controller，能让状态迁移路径变得可追踪。
• 业务规则需要被反复测试和保护：金融计算、订单规则、校验逻辑——这些地方的规则必须能脱离界面单测。分层是唯一的现实解。
• 团队协作、界面需要频繁迭代：设计师/前端频繁改界面时，只要 Model 与 Controller 的契约稳定，界面改动就不需要后端逻辑同学参与。
• Qt 的 Model/View 天然场景：你要展示列表、表格、树（QListView/QTableView/QTreeView），就应该老老实实写 QAbstractItemModel 子类，而不是往 QTableWidget 里塞数据。数据量大（万级以上行）时，Qt item widget 系列会因为每个单元格都是一个真实对象而卡死，而 Model/View 只按需取可视区域数据，性能差一个数量级。
• 需要跨前端复用逻辑：核心逻辑用 Qt/C++ 写成 Model，前端可以同时是 Widgets、QML 甚至一个 HTTP 接口，逻辑一份。

❌ 不适合的场景：

• 一次性小工具：一个 50 行就能写完的"点击按钮生成 UUID"弹窗，硬套三件套只会让读者多跳三个文件。分层有固定成本，收益不达标时就是负收益。
• 几乎无状态、无业务规则的纯展示页：如果只是把一段静态文本画出来，没有可变的 Model，那就没有需要分开的东西。
• 原型验证阶段（Spike）：还没确定需求时，先写耦合代码快速验证，等需求稳定再重构。过早架构和过晚架构一样有害。（可以配合 Day 的 spike 思路：先验证，再决定要不要铺 MVC。）
• 对延迟极度敏感、要求极致简单的嵌入式裸机 UI：额外的间接层可能带来不可接受的资源开销（虽然通常很小，但需实测）。

对比对象	核心差异	怎么选
MVC vs MVP vs MVVM	三者都是"数据-界面-调度"三件套，差别在中间层与 View 的耦合方式：MVC 中 Controller 通常还持有 View 的具体引用（View 与 Controller 双向）；MVP 的 Presenter 面向一个抽象的 IView 接口，View 极薄、几乎无逻辑，测试性最好；MVVM 的 ViewModel 通过数据绑定（Qt 里是 Q_PROPERTY + NOTIFY 信号 + QML binding）与 View 自动同步，中间层甚至不知道 View 存在。	Qt Widgets 传统项目 → MVC/MVP；Qt Quick/QML 项目 → MVVM（因为 QML 的绑定机制就是为 MVVM 设计的）。
MVC vs Observer	容易混淆，因为 MVC 内部的"Model 变化通知 View"就是用 Observer 实现的。但层级不同：Observer 是微观的一对多通知机制（一个 subject 通知多个 observer）；MVC 是宏观的架构分层——它包含了 Observer，还额外规定了"谁改数据、谁画界面、谁翻译输入"的职责边界。可以说：MVC = 角色划分 + Observer 通道 + 单向数据流约定。	Qt 里 signals/slots 就是 Observer 的实现；写 MVC 时你不必手写观察者列表，用 signal 即可。
MVC vs Mediator	Mediator（Day 16）聚焦"多个对象之间的通信爆炸"，让它们只跟中介者说话，把 N×N 通信降到 N×1；MVC 聚焦"职责分层"。在复杂界面里两者常叠加：Controller/ViewModel 同时充当 Mediator 的角色，协调多个子 View 之间的联动。	界面里出现"改 A 要联动 B、C、D"时，在 MVC 之上再引入 Mediator 思维。
MVC vs Command	不冲突，是搭档。Controller 收到"删除"意图后，理想做法不是直接 removeTask()，而是构造一个 RemoveTaskCommand 交给执行器——这样 Undo/Redo 免费得到（Day 的 QUndo 阶段会展开）。Controller 负责"翻译意图"，Command 负责"把意图变成可撤销的动作对象"。	有 Undo/Redo、宏操作、操作日志需求时，把 Controller 里的写操作升级为 Command。

一句话区分：Observer 管"通知"，Command 管"动作对象化"，Mediator 管"通信收口"，MVC 管"职责分层"。三个 GoF 模式是零件，MVC 是用这些零件搭起来的建筑结构。

MVC 在 Qt 里不是"可以用"，而是框架的骨架。抓住这几个类，你就抓住了 Qt 架构的半壁江山：

• QAbstractItemModel（纯 Model）：它是所有数据源的抽象基类，只定义"我有多少行/列、某格数据是什么、我要改数据了"（beginInsertRows/endInsertRows、dataChanged）。它不包含任何绘制代码——这正是 MVC 中"Model 不认识 View"的强制体现。
• QModelIndex（数据的坐标）：一个轻量的、供 View 使用的"位置句柄"，包含行、列和指向 Model 的指针。它不持有数据本身，是"读取坐标"而非"数据副本"——避免 View 缓存数据造成不同步。
• QAbstractItemView / QListView / QTableView / QTreeView（View，含输入）：负责绘制可视区域、处理鼠标键盘、发起编辑。Qt 官方明确说这个 View 合并了经典 MVC 中 View 与 Controller 的角色。
• QStyledItemDelegate（Delegate）：Qt 的独有补充。它负责"如何画一个单元格"（paint()）和"如何为它提供编辑器"（createEditor()/setModelData()）。Delegate 的存在让"渲染细节"从 View 里再剥一层出来，你可以给同一个 QTableView 换不同 Delegate 得到完全不同的观感。
• QItemSelectionModel（选择状态）：它独立保存"哪些项被选中"，与 Model 的数据、View 的显示都解耦。所以同一份数据可以被多个 View 共享选择状态，也可以各自独立选择——这是把"交互状态"当成独立模型的漂亮示范。
• QSortFilterProxyModel（ViewModel 味道的中间层）：它夹在 Model 与 View 之间，提供排序/过滤而不改动源 Model。这是一个"装饰型 Model"，把"数据的呈现顺序"这一层职责单独抽出，是 MVC 分层思想的延伸。
• signals/slots 与 Q_PROPERTY：前者是 Observer 通道（Model 广播变化）；后者配合 NOTIFY 信号构成 MVVM 的数据绑定基础。Qt 用同一套元对象系统同时支撑 MVC 和 MVVM 两种架构。

代码特征信号（看到这些，基本可以断定这里有 MVC 的影子）：

1. 一个不包含任何 #include <QWidget> / 界面类型的数据类，能独立编译进控制台程序并被单测；
2. Model 内部有 beginInsertRows/endInsertRows、emit dataChanged 或自建的 notify() 广播，且广播出去的内容只有"数据坐标/值"；
3. View 里出现的是 render(data) / data(index, role) 这类只读调用，找不到 if (业务规则)；
4. 所有 connect(...) 或回调接线集中在 Controller / main 的构造函数里，像一张清晰的电路图；
5. 新增一个视图（或一个导出功能）时，Model 与 Controller 的 diff 是 0 行——这是 OCP 达标的硬指标。

今日避坑清单：① Model 里禁止弹窗、禁止持有控件指针；② 禁止在别处绕过 Model 直接改数据；③ 不要为了分层而分层，先感到"痛"再拆；④ QTableWidget 是便利 API 不是架构，规模一大必须换 QTableView + QAbstractItemModel。

明日预告 · Day 25：MVVM 与数据绑定（Model-View-ViewModel）。MVC 里 Controller 还得拿着 View 的引用去"命令"界面刷新；MVVM 更彻底——ViewModel 只暴露可绑定的属性（Q_PROPERTY ... NOTIFY），界面通过 bindable 自动同步，ViewModel 甚至不知道 View 长什么样。我们将用 Qt6 的 QBindable/Property Binding 写一个"输入框 ↔ Model 双向自动同步"的例子，并对比 MVC/MVP/MVVM 三者的测试成本差异。届时你会看到：从 MVC 到 MVVM，本质是把"手动刷新"这条线也交给框架。