MVC / MVP / MVVM / Elm Architecture同一道题的四代解法仓库已经开源喜欢的话点个⭐仓库Win32和Win32图形栈的部分目前已完成教程力争做一个完备的GUI教程欢迎各位大佬前来参观https://github.com/Charliechen114514/anatomy_gui开源系列文档站正在维护点击阅读https://charliechen114514.github.io/anatomy_gui/MVC、MVP、MVVM——这几个词儿长得像、意思近头一回撞见很容易绕进去它们到底有啥不一样为啥前人要发明这么多差不多的缩写是不是就为了把后辈绕晕后来读了一圈才回过味来它们不是平行发明的几套东西而是同一道题、四代人交的不同答卷每一代都在修上一代踩的坑。那这道「题」到底是什么这族模式要解的题状态—视图—输入的三角循环任何一个交互式应用不管它挂什么模式的牌子都得对付仨东西状态应用真正关心的东西——计数器的值、文档的内容、当前登录的用户。视图把状态画出来给人看的那一层。输入用户的操作——点击、键盘、手势是人想改变状态的途径。这三者之间天然有个循环输入改状态 → 状态变 → 视图跟着变 → 人看到新界面 → 再输入……改驱动人看到·再操作输入状态视图这个圈绕得顺应用就丝滑绕不好就是各种状态对不上账、界面乱闪、逻辑缠成一团。MVC、MVP、MVVM、Elm Architecture全是奔着「把这个循环组织清楚」去的。下头一代一代看看它们各自怎么画这个圈又各自修了前人什么毛病。第一代 · MVC1979三角分开各管一摊最老的 MVC1979 年在 Xerox PARC 的 Smalltalk 里由 Trygve Reenskaug 提出咱们在 T01 引过他那份原始笔记。想法很清爽三角分三个角色Model是状态它不关心谁在看它View订阅 Model、把它画出来Controller接用户的输入、决定怎么动 Model。漂亮是漂亮可真用起来坑就来了Controller 和 View 的边界会糊。Controller 到底管不管界面逻辑View 要不要知道输入后来 Web 时代的人又把 MVC 重新解释了一通Model 当数据库、View 当模板、Controller 当路由跟原始含义早不是一回事了。Fowler 在GUI Architectures里就吐槽过——MVC 压根不是一个模式它是一捆想法的集合谁看谁抽走一部分。这话说得毒但准。第二代 · MVP让 View 闭嘴Presenter 居中为治「Controller/View 边界糊」这个病1990 年代有了 MVPModel-View-Presenter。关键一刀把 View 变成一个完全被动的笨蛋所有协调全搬到 Presenter 那儿。View 只管「展示」和「把用户动作转给 Presenter」它不直接碰 Model、不做任何决策。Presenter 是大脑——从 View 拿到动作、动 Model、再让 View 刷新。这么一来View 可以做成哑巴的、可替换的Presenter 不依赖具体 View单元测试也好写了。代价呢Presenter 自己越长越胖所有界面逻辑全堆它身上到头来又成一坨。第三代 · MVVMViewModel 是为 View 量身定做的 Model到了 2000 年代WPF 团队搞出 MVVMModel-View-ViewModel。最关键的一笔是ViewModel——一个专门为某个 View 准备的「视图状态」。View 不再像 MVP 那样被 Presenter「命令刷新」而是通过数据绑定订阅 ViewModelViewModel 的属性一变View 自动跟着变。「我命令你刷新」那种话全省了。数据绑定自动用户动作command改·读ViewModel视图状态ViewModel业务数据瞧出来没MVVM 把「状态绑定」这个器官T01 第 10 个器官直接提拔成了整个模式的招牌——ViewModel 这个角色存在的全部意义就是被 View 绑定。这就是为什么一提状态绑定大家头一个想到的就是 MVVM这层关系咱们在 T01 第 10 已经点破过。Fowler 自己更早提过一个叫 Presentation Model 的模式MVVM 基本就是它嫁接到 WPF 数据绑定上的产物。第四代 · Elm Architecture把循环写成纯函数到 Elm 这儿整个思路被函数式风格重洗了一遍。三角还是那个三角但全变成了纯函数 不可变数据Model是不可变状态view : Model - Html是纯函数把状态变成界面描述update : Msg - Model - Model也是纯函数一条消息把旧状态变成新状态。view 纯函数产生update 纯函数Model不可变View界面描述Msg消息新 Model为什么 Elm、Redux 这种「单向数据流」特别适合把状态循环讲清楚因为它把每一步都掰开了状态只能被update改、界面只能由view算、动作只能打包成Msg——没有一条暗道数据流向一目了然调试的时候跟得清清楚楚。四代一张图每代修了上一代什么Controller/View 边界糊Presenter 越堆越胖命令式刷新仍隐晦MVC · 1979三角分开各管一摊MVP · 1990sView 被动Presenter 居中MVVM · 2000sViewModel 数据绑定Elm Architecture纯函数 单向数据流每一代都不是推翻上一代而是专治上一代最扎手的那个痛点。所以别把它们当对立的派别——它们是同一道题的四代答卷。今天您选哪一代看手里的语言、框架和最让您头疼的是哪类毛病。所以收尾看看——这族模式解的全是「状态—视图—输入」这个循环怎么组织——它是 T01 第 10 个器官状态绑定的「架构层」表亲跟状态绑定的「机制层」正交T01 第 10 已划过这条界。它们是演进关系不是对立关系——MVC 起头MVP 治它的 Controller/View 糊MVVM 治 Presenter 胖顺手把状态绑定提成招牌TEA 用纯函数治「数据流难追踪」。本书的 MiniUI 不会把您绑死在任何一代上。但等您亲手造完自己的状态系统见 T03 那三级台阶再回头看这四代就会明白它们各自在替您省哪份心、又各自把哪份累赘藏进了框架肚子里。
通用GUI技术编程指南：MVC / MVP / MVVM / Elm Architecture：同一道题的四代解法
MVC / MVP / MVVM / Elm Architecture同一道题的四代解法仓库已经开源喜欢的话点个⭐仓库Win32和Win32图形栈的部分目前已完成教程力争做一个完备的GUI教程欢迎各位大佬前来参观https://github.com/Charliechen114514/anatomy_gui开源系列文档站正在维护点击阅读https://charliechen114514.github.io/anatomy_gui/MVC、MVP、MVVM——这几个词儿长得像、意思近头一回撞见很容易绕进去它们到底有啥不一样为啥前人要发明这么多差不多的缩写是不是就为了把后辈绕晕后来读了一圈才回过味来它们不是平行发明的几套东西而是同一道题、四代人交的不同答卷每一代都在修上一代踩的坑。那这道「题」到底是什么这族模式要解的题状态—视图—输入的三角循环任何一个交互式应用不管它挂什么模式的牌子都得对付仨东西状态应用真正关心的东西——计数器的值、文档的内容、当前登录的用户。视图把状态画出来给人看的那一层。输入用户的操作——点击、键盘、手势是人想改变状态的途径。这三者之间天然有个循环输入改状态 → 状态变 → 视图跟着变 → 人看到新界面 → 再输入……改驱动人看到·再操作输入状态视图这个圈绕得顺应用就丝滑绕不好就是各种状态对不上账、界面乱闪、逻辑缠成一团。MVC、MVP、MVVM、Elm Architecture全是奔着「把这个循环组织清楚」去的。下头一代一代看看它们各自怎么画这个圈又各自修了前人什么毛病。第一代 · MVC1979三角分开各管一摊最老的 MVC1979 年在 Xerox PARC 的 Smalltalk 里由 Trygve Reenskaug 提出咱们在 T01 引过他那份原始笔记。想法很清爽三角分三个角色Model是状态它不关心谁在看它View订阅 Model、把它画出来Controller接用户的输入、决定怎么动 Model。漂亮是漂亮可真用起来坑就来了Controller 和 View 的边界会糊。Controller 到底管不管界面逻辑View 要不要知道输入后来 Web 时代的人又把 MVC 重新解释了一通Model 当数据库、View 当模板、Controller 当路由跟原始含义早不是一回事了。Fowler 在GUI Architectures里就吐槽过——MVC 压根不是一个模式它是一捆想法的集合谁看谁抽走一部分。这话说得毒但准。第二代 · MVP让 View 闭嘴Presenter 居中为治「Controller/View 边界糊」这个病1990 年代有了 MVPModel-View-Presenter。关键一刀把 View 变成一个完全被动的笨蛋所有协调全搬到 Presenter 那儿。View 只管「展示」和「把用户动作转给 Presenter」它不直接碰 Model、不做任何决策。Presenter 是大脑——从 View 拿到动作、动 Model、再让 View 刷新。这么一来View 可以做成哑巴的、可替换的Presenter 不依赖具体 View单元测试也好写了。代价呢Presenter 自己越长越胖所有界面逻辑全堆它身上到头来又成一坨。第三代 · MVVMViewModel 是为 View 量身定做的 Model到了 2000 年代WPF 团队搞出 MVVMModel-View-ViewModel。最关键的一笔是ViewModel——一个专门为某个 View 准备的「视图状态」。View 不再像 MVP 那样被 Presenter「命令刷新」而是通过数据绑定订阅 ViewModelViewModel 的属性一变View 自动跟着变。「我命令你刷新」那种话全省了。数据绑定自动用户动作command改·读ViewModel视图状态ViewModel业务数据瞧出来没MVVM 把「状态绑定」这个器官T01 第 10 个器官直接提拔成了整个模式的招牌——ViewModel 这个角色存在的全部意义就是被 View 绑定。这就是为什么一提状态绑定大家头一个想到的就是 MVVM这层关系咱们在 T01 第 10 已经点破过。Fowler 自己更早提过一个叫 Presentation Model 的模式MVVM 基本就是它嫁接到 WPF 数据绑定上的产物。第四代 · Elm Architecture把循环写成纯函数到 Elm 这儿整个思路被函数式风格重洗了一遍。三角还是那个三角但全变成了纯函数 不可变数据Model是不可变状态view : Model - Html是纯函数把状态变成界面描述update : Msg - Model - Model也是纯函数一条消息把旧状态变成新状态。view 纯函数产生update 纯函数Model不可变View界面描述Msg消息新 Model为什么 Elm、Redux 这种「单向数据流」特别适合把状态循环讲清楚因为它把每一步都掰开了状态只能被update改、界面只能由view算、动作只能打包成Msg——没有一条暗道数据流向一目了然调试的时候跟得清清楚楚。四代一张图每代修了上一代什么Controller/View 边界糊Presenter 越堆越胖命令式刷新仍隐晦MVC · 1979三角分开各管一摊MVP · 1990sView 被动Presenter 居中MVVM · 2000sViewModel 数据绑定Elm Architecture纯函数 单向数据流每一代都不是推翻上一代而是专治上一代最扎手的那个痛点。所以别把它们当对立的派别——它们是同一道题的四代答卷。今天您选哪一代看手里的语言、框架和最让您头疼的是哪类毛病。所以收尾看看——这族模式解的全是「状态—视图—输入」这个循环怎么组织——它是 T01 第 10 个器官状态绑定的「架构层」表亲跟状态绑定的「机制层」正交T01 第 10 已划过这条界。它们是演进关系不是对立关系——MVC 起头MVP 治它的 Controller/View 糊MVVM 治 Presenter 胖顺手把状态绑定提成招牌TEA 用纯函数治「数据流难追踪」。本书的 MiniUI 不会把您绑死在任何一代上。但等您亲手造完自己的状态系统见 T03 那三级台阶再回头看这四代就会明白它们各自在替您省哪份心、又各自把哪份累赘藏进了框架肚子里。
