tkinter 本身不提供 mvc 框架，但可通过纯 python + ttk + 显式分层实现真正 mvc，核心在于严格隔离 model/view/controller 职责；tkinter-mvc 库仅是轻量模板，违反 mvc 原则，缺乏异步支持、状态管理与可测试性。
直接说结论：Tkinter 本身不提供 MVC 框架，但你可以用纯 Python + ttk + 显式分层来实现真正的 MVC，关键不在“有没有框架”，而在“是否严格隔离 Model/View/Controller 的职责边界”。
为什么不能直接用 tkinter-mvc 库？
它名字带“MVC”，但实际是个轻量模板项目，不是生产级框架。它的 Model 类只是个空基类，View 里混着 bind 和布局代码，Controller 经常直接操作 self.view.tree.insert(...)——这已经违反了 MVC 原则（View 不该被 Controller 直接写入数据）。真实大型项目中，这种写法三个月后就没人敢改按钮逻辑了。
- 它没解决事件循环阻塞时的异步响应问题（比如点击“加载学生列表”后界面卡住）
- 没有内置状态管理，View 层容易出现“按钮点了两次才生效”或“表格刷新后选中项丢失”
- 测试困难：
Controller依赖tk.Tk()实例，单元测试得 mock 整个 Tk 环境
Treeview 数据绑定必须绕开“直接 insert”
很多人把数据库查出的 list[dict] 循环调用 tree.insert('', 'end', values=...)，这看似简单，实则埋下大坑：数据和 UI 强耦合、无法统一控制排序/过滤/高亮、删除某行还得手动记 index。
- 正确做法是让
Model提供一个可观察的数据容器，比如封装成StudentList类，内部用list存原始数据，暴露.items（只读属性）、.add(item)、.remove_by_id(id)等方法 -
View只监听Model的变更信号（可用functools.partial或自定义事件），收到通知后全量重绘或增量更新Treeview - 避免在
Controller里写tree.delete(*tree.get_children())—— 这属于 View 内部细节，应由 View 自己决定清空策略（比如加 loading 动画）
Controller 必须禁止访问 root 或 mainloop
常见错误是把登录成功后的跳转写成 root.destroy(); AdminView().show()，这导致 Controller 承担了窗口生命周期管理，彻底破坏分层。结果就是：想给管理员界面加个“返回上一页”按钮时，发现 Controller 根本不知道自己从哪来。
- Controller 只负责业务流转，比如
on_login_success(username, role)，然后调用self.navigator.to_admin_panel(username, role) -
navigator是独立模块，管理窗口栈或主区域 content 切换，它才知道root是什么、怎么销毁/隐藏/复用 - 所有弹窗（如报修提交成功提示）必须由 View 自己触发，Controller 只发“提交完成”事件，不指定用
messagebox.showinfo还是 Toast 式浮层
SQLite 操作必须收口到 Model 层
看到有人在 Button 的 command 里直接写 conn.execute("UPDATE ...")，这是典型的“伪 MVC”——数据库连接满天飞，事务控制失效，连表查询根本没法复用。
- Model 层提供原子方法，如
StudentModel.update_room(student_id, new_dorm_id)，内部处理连接、事务、异常转换（把sqlite3.IntegrityError转为自定义DuplicateRoomAssignmentError） - View 层永远不 import
sqlite3，Controller 层也不拼 SQL 字符串 - 如果未来要换 MySQL，只需重写 Model 中的几个方法，View 和 Controller 一行代码都不用动
真正难的不是写三层文件夹，而是每次加功能时都问自己一句：“这个变量/函数/导入，放在当前层是否违背了‘只做这一件事’的契约？”——比如 Treeview 的列宽配置写在 View 类的 __init__ 里是对的，但写在 Controller 的初始化方法里，就已经越界了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
