当项目出现main.py超800行、改显示需动三处逻辑、无法单元测试“查学生”动作时，必须拆分MVC；Model须拒绝非法状态，View只负责渲染和转发事件，Controller专注协调业务动作与错误处理。
大型 Tkinter 项目一旦逻辑和界面混在一起，update()卡顿、destroy()后残留绑定、改个按钮就要翻遍三个文件——说明它已经到了必须用 MVC 拆分的临界点。不重构，后续加功能就是修修补补的负向循环。
什么时候该拆？看这三条硬指标
不是所有项目都需要 MVC，但满足以下任一条件就该动手：
-
main.py超过 800 行，且class App(tk.Tk)里同时包含数据库查询、ttk.Treeview插入逻辑、输入校验、导出 Excel 代码 - 改一个字段显示格式（比如学号加前缀），要同时动界面布局、数据读取、事件回调三处
- 测试时只能靠人工点按钮，没法对“查学生”这个动作单独写单元测试，因为逻辑全绑在
def on_search_click(self):里
Model 层不能只存数据，得管住边界
Model 不是简单的字典容器，它的核心职责是“拒绝非法状态”。比如学生信息 Model 必须阻止空姓名、重复学号、邮箱格式错误被写入内存或文件。
- 用
@property+setter封装字段，而不是直接暴露self.name = value - 验证逻辑写在 Model 内部，例如
def set_email(self, email):里调用re.match(...)，失败就抛ValueError - 持久化方法（如
save_to_csv()）只接收已验证过的 Model 实例，不接受原始字符串或字典 - 避免在 Model 里 import
tkinter或任何视图相关模块——这是耦合高发区
View 层只做两件事：画和喊
View 的唯一合法行为是：把 Model 数据“画出来”，把用户操作“喊出去”。它不该知道数据从哪来、校验规则是什么、保存成功后要不要弹窗。
立即学习“Python免费学习笔记（深入）”；
- 所有控件（
ttk.Entry、ttk.Treeview）只通过set()/insert()接收数据，不主动调用 Model 方法 - 按钮的
command=必须指向 Controller 提供的回调函数，禁止写lambda: self.model.delete(...) - 监听
<FocusOut>这类事件时，只做“取值+喊给 Controller”，不自己做非空判断 - 如果要用
StringVar绑定输入框，确保它只在 View 内部使用，Controller 通过接口方法获取其值，而非直接访问变量
Controller 是胶水，不是搬运工
Controller 的代码最容易写成“中间人综合征”——从 View 取值 → 传给 Model → 拿回结果 → 再塞回 View。真正该它做的，是协调时机与责任归属。
- 一个 Controller 方法对应一个明确业务动作，例如
handle_student_add()，而不是on_button_click() - 它决定“什么时机更新 View”：比如保存成功后，是清空表单（
self.view.clear_form()），还是刷新列表（self.view.refresh_list()），而不是让 Model 去通知 View - 错误处理统一出口：Model 抛异常 → Controller 捕获 → 调用
self.view.show_error("学号已存在")，View 决定用messagebox还是底部状态栏显示 - 避免在 Controller 里写 SQL 或文件路径硬编码，这些应下沉到 Model 的具体实现类中（如
CsvStudentRepository）
最难的不是分三层，而是守住边界。比如一个搜索框回车触发查询，Controller 必须确保：View 只负责把回车事件发出来，Model 只负责返回匹配的学生列表，而“列表为空时是否显示提示文字”这个决策，必须由 View 根据 Controller 传来的空列表自行判断——不是 Controller 去调 view.show_no_results_hint()。
