想象你走进一家餐厅。顾客坐在餐桌前，服务员穿梭于餐桌和后厨之间，后厨的厨师们只管把食材变成菜肴。高峰期时，服务员要记住几十桌的订单，还得在出菜口和餐桌之间来回跑——传统餐厅就是这么运转的：一切靠服务员中转，顾客不能直接冲进厨房，后厨也不会跑出来上菜。 后来，这家餐厅升级成了智能餐厅：每张餐桌前有一块点餐屏，你点一下，订单自动传往后厨；菜一出锅，传送带自动把菜送到你面前。没有服务员来回跑动，一切自动同步——这就是MVVM。 架构模式，就是餐厅的分工制度。MVC是“服务员中转制”，MVVM是“自动传送带制”，MVP则相当于请了一位“传菜经理”统筹调度。选哪种制度，决定了餐厅（项目）的效率、成本和可维护性。接下来，我们把这三套“餐厅分工制度”拆开看个明白。

岗位关联

对AI从业者而言，理解MVC与MVVM是读懂Vue、React等现代前端框架设计思想的基石，也是走向组件化、响应式编程思维的一次关键升级。

目录
  1. 可视化演示
  2. MVC职责划分
  3. MVP中间层
  4. MVVM核心机制
  5. 数据绑定机制
  6. 前端框架实践
  7. 模式对比选型
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示无向图、有向图与加权图三种图模型，演示邻接矩阵与邻接表的表示方法。

本节配有交互动效（进入视口后自动加载，约 3KB）。

图论基础 无向图：边没有方向，(u,v)=(v,u) 有向图：边有方向，(u,v)≠(v,u) 加权图：每条边附带权重

MVC职责划分

传统餐厅里，顾客（View）坐在餐桌前，服务员（Controller）负责记单，后厨（Model）负责做菜。顾客想加菜就对服务员说，服务员跑后厨下单，后厨做好再让服务员端出来。顾客绝不会直接冲进厨房，后厨也绝不会自己跑出来上菜——所有信息都绕着服务员转一圈。这就是MVC的第一印象：三个角色通过“沟通制度”各司其职。

MVC（Model-View-Controller）的核心约定是“单向数据流”。Model只管数据和业务规则，相当于后厨；View只管界面展示，相当于顾客眼前的餐桌；Controller接收用户输入并调度Model，相当于服务员。以登录页面为例：用户点击登录按钮（View捕获点击事件），Controller收到事件后调用Model的验证逻辑，验证成功后再通知View跳转主页。View不写业务逻辑，Model不关心按钮在哪。

可见MVC像“点单—下单—出菜—上桌”的餐厅闭环，分工清晰。但问题也随之而来：所有分支逻辑都压在服务员（Controller）身上，随着页面变复杂，Controller会越来越臃肿，这正是后来两种模式试图解决的核心痛点。

View→用户操作Controller→更新数据Model→变化通知View\text{View} \xrightarrow{\text{用户操作}} \text{Controller} \xrightarrow{\text{更新数据}} \text{Model} \xrightarrow{\text{变化通知}} \text{View}
这条链描述了一次完整的MVC交互：用户操作驱动视图产生事件，控制器负责调用模型，模型变化后通知视图刷新，形成闭环。
  1. 起点 View用户看到的界面，例如登录按钮与输入框。它只负责把用户动作变成事件抛出去。$V$ 表示此刻的视图状态。
  2. Controller 中介接收 View 抛来的事件，决定调用哪个业务方法。$V \xrightarrow{\text{事件}} C$ 中的箭头表示“界面事件被控制器接管”。
  3. Model 更新数据Controller 调用 Model 的方法，业务逻辑在后厨完成。$C \xrightarrow{\text{调用}} M$ 表示控制器只是通知者，真正的计算在模型里。
  4. View 刷新闭环Model 数据变化后通过订阅机制通知 View，视图展示新状态。$M \xrightarrow{\text{变化通知}} V$ 让整个闭环重新回到界面。

MVP中间层

MVP的餐厅升级了：服务员被升级成“传菜经理”（Presenter）。他不仅负责点单，还主动盯着后厨——菜一做好，他立刻端上桌，还会按顾客口味做微调（把数据加工成视图想要的格式）。顾客（View）彻底变成“甩手掌柜”，只负责举手示意和享受上菜。

MVP（Model-View-Presenter）把Controller换成了Presenter，最大的变化是：View连“读Model”的权限都被收走。所有交互逻辑都集中到Presenter中，它监听View的事件、调用Model取数、再把返回的数据手动“塞”给View刷新。View与Model互相不认识，所有通信都必须穿过Presenter。这一设计在Android开发中很常见：Activity实现View接口，Presenter持有View接口与Model的引用，测试时可以轻松替换成mock的View。

传菜经理统筹全局，让餐厅的服务质量和测试难度都变得可控，但代价是经理很累：每道菜怎么端、怎么摆都要亲自盯着。MVP的代码量偏大，View接口需要定义大量事件方法，中小型项目用起来会显得笨重。

View→事件Presenter→取数Model→回传Presenter→手动渲染View′\text{View} \xrightarrow{\text{事件}} \text{Presenter} \xrightarrow{\text{取数}} \text{Model} \xrightarrow{\text{回传}} \text{Presenter} \xrightarrow{\text{手动渲染}} \text{View}'
这条链直观展示了MVP的双程往返：事件从View进入Presenter，数据从Model返回Presenter后，由Presenter手动驱动视图更新。
  1. View 抛事件$V \to P$，View 把按钮点击等事件交给 Presenter，自己不处理任何业务。
  2. Presenter 取数$P \to M$，Presenter 调用 Model 接口发起请求，等待数据返回。
  3. Model 回传$M \xrightarrow{\text{回调}} P$，数据通过回调或 Promise 回到 Presenter 手中。
  4. 手动渲染关键步$P \xrightarrow{\text{手动渲染}} V'$，Presenter 拿着数据调用 View 接口的方法刷新界面——“手动”二字正是与 MVVM 划清界限的关键。

MVVM核心机制

MVVM餐厅装的是智能餐桌。餐桌上有点餐屏（View），厨房里有总控电脑（Model），两者之间连着一根“数据传送带”（ViewModel）。你在屏幕上选菜，传送带自动把订单送往厨房；厨房改价或售罄，传送带自动把新菜单推送到你眼前。全程没有服务员来回跑，一切都自动同步。

MVVM（Model-View-ViewModel）把View的状态与逻辑抽到ViewModel中。ViewModel是View的“状态镜像”：界面上显示的每个字段都能在ViewModel里找到对应属性。双方通过双向数据绑定自动同步——View的属性变化会写入ViewModel，ViewModel的属性变化也会自动画到View上。以Vue为例，data中定义的对象对应Model，模板对应View，Vue实例扮演了ViewModel的角色。当执行this.name = '新值'时，响应式系统能精确定位依赖该数据的组件并触发重渲染，开发者完全不需要写document.getElementById(...).textContent = ...这类命令式更新代码。

智能餐厅省掉了跑腿的服务员，开发效率大幅提升，但传送带一旦出故障（属性更新没触发视图、依赖没收集到），排查起来比传统模式更费劲。而且街边小店装一套智能系统纯粹是负担——这就是为什么MVVM适合交互密集的现代前端，却不适合简单静态页面。

View⟷双向绑定ViewModel⟶自动同步Model\text{View} \overset{\text{双向绑定}}{\longleftrightarrow} \text{ViewModel} \overset{\text{自动同步}}{\longrightarrow} \text{Model}
这个式子说明MVVM的本质：View与ViewModel之间是双向关系，ViewModel与Model之间是单向同步关系，开发者主要维护ViewModel即可。
  1. 双向绑定箭头$\overset{\text{双向绑定}}{\longleftrightarrow}$ 表示View的输入会写进ViewModel，ViewModel的状态变化也会渲染回View。
  2. ViewModel 同步 Model$\text{ViewModel} \xrightarrow{\text{自动同步}} \text{Model}$ 表示业务状态被自动提交给模型层。
  3. Model 变化回流（隐含）Model数据更新后，ViewModel感知变化并广播，最终驱动View重新渲染，形成完整闭环。

数据绑定机制

智能餐厅的传送带不是魔法，底下藏着传感器和信号线。对应到技术里，“传感器与信号线”就是观察者模式和数据劫持机制。理解了这些底层机关，你才能真正解释“为什么数据一变，界面就变”。

数据绑定分为单向绑定（Model → View）和双向绑定（View ↔ Model）。传统MVC是“手动单向”：Model变化后需要你手动调用刷新方法。MVVM则是“自动双向”：框架在底层建立订阅关系。实现订阅关系的三种主流机制是：观察者模式（View订阅Model，变化时自动通知）、脏检查（AngularJS在每次事件循环后比较整个数据树）、数据劫持+依赖收集（Vue通过Object.defineProperty或Proxy拦截属性读写，并记录哪些视图依赖该属性）。以Vue2为例：首次渲染时组件读取了某个属性，触发getter，把组件登记为“依赖者”；之后任何代码修改该属性，setter就会通知这个组件重新渲染。

传送带上的每个托盘都有专属传感器，只有你的订单对应的托盘移动时，你的餐桌才会收到信号。这也是MVVM能实现“精准同步”、避免无谓刷新的底层原因。

∑iΔMi  ⇒  通知所有订阅的 View 组件  ⇒  视图自动刷新\sum_{i} \Delta M_i \;\Rightarrow\; \text{通知所有订阅的 View 组件} \;\Rightarrow\; \text{视图自动刷新}
这个公式表示：任何一个被观察的属性发生变化，都会触发一次精准的通知链路，只刷新真正依赖它的视图组件。
  1. 变化累加$\sum_{i} \Delta M_i$ 表示任意一个被观察属性（或多个属性）发生变化，都算作一次数据增量。
  2. 触发箭头$\Rightarrow$ 表示“只要增量发生，就必须走通知链路”的强绑定关系。
  3. 订阅集合“通知所有订阅的 View 组件”指依赖收集阶段建立的订阅者名单。没有被谁订阅的属性，变化时不会引起任何重渲染。

前端框架实践

同样是现代化餐厅，Vue选择了全面智能（MVVM），React则走了一条“精细化流程管理”路线：顾客的每个动作都通过标准工单传达，厨房每完成一步就通过新菜单快照重新上菜。两者理念不同，但都活得很好。

Vue是学习MVVM思想最直观的框架。v-model是双向绑定的语法糖，<input v-model="name">等同于同时执行了:value="name"和@input="name = $event.target.value"——先单向绑定数据到界面，再监听输入事件把值写回数据。React则强调单向数据流：组件状态（state）通过render流向界面，用户事件回调里调用setState更新状态，再触发新一轮render。这种“事件回调驱动状态更新”的思路与MVC中的Controller一脉相承：事件处理函数就是Controller，负责更新数据模型。

Vue的智能餐桌省心省力，React的工单系统多写几行但每一步都有据可查。选哪个不是对错问题，而是你的团队更看重“开发效率”还是“可追踪性”。

Vue: v-model≈单向绑定+事件监听,React: State→渲染View→回调setState→State\text{Vue: } v\text{-model} \approx \text{单向绑定} + \text{事件监听},\qquad \text{React: State} \xrightarrow{\text{渲染}} \text{View} \xrightarrow{\text{回调}} \text{setState} \to \text{State}
这个式子对比了两者的核心差异：Vue把“数据到界面”和“界面到数据”合并成一条指令，React则坚持让数据流只沿一个方向闭环。
  1. v-model 近似式$v\text{-model} \approx \text{单向绑定} + \text{事件监听}$ 说明它只是便捷写法，底层本质是两件事的合并。
  2. React 前半段$\text{State} \xrightarrow{\text{渲染}} \text{View}$ 表示状态驱动界面渲染，方向唯一。
  3. React 后半段$\text{View} \xrightarrow{\text{回调}} \text{setState} \to \text{State}$ 表示用户操作后通过回调把新状态设置回去，构成有向闭环。

模式对比选型

三种餐厅各有拥趸。街边小面馆请一两个服务员就够（MVC）；需要严格控制服务体验的星级餐厅会配传菜经理（MVP）；追求翻台率的连锁快餐则上智能系统（MVVM）。选制度就是选适配度，没有绝对的好坏。

从工程角度看：MVC简单直观、上手最快，但Controller容易膨胀，适合小型应用、后端传统Web开发，或作为团队学习架构的起点。MVP把View与Model彻底解耦、可测试性最强，但需要写大量接口与回调，适合Android、桌面端等对测试要求高的场景。MVVM开发效率最高、状态同步零手工，但绑定链路的排查成本高，适合Vue/React等现代前端项目。选型时可以用三个指标打分：业务复杂度（状态多不多、交互密不密集）、团队熟悉度（用已知技术解决业务）、测试要求（是否有完善单测体系）。

餐厅的成功不取决于装不装智能系统，而取决于菜品、人员和制度的匹配。架构选型也一样，MVC、MVP、MVVM各有舞台，理解它们的边界，你才能真正做到“看菜下饭，用人所长”。

最优模式=arg⁡max⁡x∈{MVC, MVP, MVVM}业务适配(x)×团队熟悉(x)综合成本(x)\text{最优模式} = \arg\max_{x \in \{\text{MVC},\ \text{MVP},\ \text{MVVM}\}} \frac{\text{业务适配}(x)\times\text{团队熟悉}(x)}{\text{综合成本}(x)}
这个公式建议你选择“性价比”最高的模式：分子是适配度与熟悉度的乘积，分母是包含学习、开发、维护的综合成本。
  1. 候选集合$x \in \{\text{MVC},\ \text{MVP},\ \text{MVVM}\}$ 列出三个候选，选型就是从这三家里挑一个。
  2. 分子乘积$\text{业务适配}\times\text{团队熟悉}$ 表示再好的模式，团队没人会也是灾难。
  3. 分母成本$\text{综合成本}$ 包含学习成本、开发成本、长期维护成本。
  4. argmax 语义$\arg\max$ 表示取让整个分式最大的那个模式，而不是“最流行”或“看起来最新的”。

AI 应用场景

电商后台商品管理页的 MVVM 重构

阶段：前端架构设计 / 数据流建模

解决的问题：传统 jQuery 时代，搜索关键词、筛选条件、商品列表三个状态散落在不同 DOM 操作中，每次变更都要手动拼接 HTML，既慢又易错。引入 MVVM 后，这些状态统一收拢到 ViewModel（如 Vue 的 data 与 computed），数据一变，列表自动重渲染，彻底告别命令式 DOM 操作。

具体案例：某电商后台的 SKU 管理页面，搜索框用 v-model 双向绑定关键词，筛选项绑定选中值，商品列表通过 computed 属性依据关键词自动过滤。运营人员输入“连衣裙”的瞬间，表格秒级刷新，无需任何手动刷新逻辑。

移动端用户资料页的 MVP 分层

阶段：中间层设计 / 单元测试保障

解决的问题：Android 页面常常把网络请求、表单校验、UI 更新全部堆在 Activity 里，方法动辄几百行，业务逻辑难以测试。采用 MVP 后，Presenter 专门负责加载资料、校验输入、保存回调，View 只负责展示结果，逻辑可以被 JUnit 单独测试。

具体案例：某 App 的“个人中心”页面，Presenter 封装 getUserInfo() 与 updateUserInfo()，Activity 只实现 View 接口的 showUser(user) 和 showError(msg)。测试时使用 mock 的 View 接口，即可在无 UI 环境下验证保存逻辑是否正确。

复杂中后台的全局状态管理

阶段：状态管理与组件通信

解决的问题：多个页面共享登录态、购物车状态时，如果每个页面各自维护一份拷贝，极易出现数据不同步。借鉴 MVVM 思想，把全局状态放进一个“全局 ViewModel”（如 Vuex / Pinia），任何组件修改 state，所有依赖该状态的组件自动更新。

具体案例：某 Saas 后台的权限系统，用户登录后把角色信息写入 Pinia store，侧边栏菜单组件与页面路由守卫都依赖同一份状态。用户切换角色后，菜单和可见页面立即联动更新，无需刷新浏览器。

Python 演示

python67 行
# 迷你 MVVM 双向绑定演示：观察者模式 + 属性集合 class ViewModel:    """充当 MVVM 中的 ViewModel，维护数据并通知订阅者"""    def __init__(self):        self._data = {}        self._watchers = {}     def set(self, key, value):        old = self._data.get(key)        if old != value:            self._data[key] = value            self._notify(key, value)     def get(self, key):        return self._data.get(key)     def watch(self, key, callback):        self._watchers.setdefault(key, []).append(callback)     def _notify(self, key, value):        for cb in self._watchers.get(key, []):            cb(value)  class TextView:    """模拟 View：展示某个字段，并接收用户输入"""    def __init__(self, vm, key):        self.vm = vm        self.key = key        self.visible_text = ""        vm.watch(key, self._on_change)     def _on_change(self, new_value):        self.visible_text = str(new_value)        print("[View] 界面显示:", self.visible_text)     def user_input(self, text):        print("[View] 用户输入:", text)        self.vm.set(self.key, text)  class DataModel:    """模拟 Model：真正的数据源，可模拟服务器推送"""    def __init__(self, vm):        self.vm = vm     def server_push(self, key, value):        print("[Model] 服务器推送:", key, "=", value)        self.vm.set(key, value)  def main():    vm = ViewModel()    vm.set("username", "Alice")    text_view = TextView(vm, "username")    model = DataModel(vm)     print("--- 场景1：用户输入触发绑定 ---")    text_view.user_input("Bob")     print("--- 场景2：服务器推送触发绑定 ---")    model.server_push("username", "Carol")  if __name__ == "__main__":    main()
目的：用不到 80 行实现一个迷你双向绑定引擎，直观演示 MVVM 中 View、ViewModel、Model 三者如何通过观察者模式自动同步。
  1. self._watchers.setdefault(key, []).append(callback)每个属性维护一张“订阅者名单”，新 View 实例化时就登记上去。
  2. vm.watch(key, self._on_change)View 订阅 ViewModel 的指定属性，这是“双向绑定”中 View 侧的自动更新钩子。
  3. self.vm.set(self.key, text)用户输入通过 ViewModel 写数据，而不是直接修改界面文本，这正是 MVVM 的核心约束。
  4. self._notify(key, value)数据变化后逐个通知订阅者，这就是“传送带自动同步”的引擎。
  5. model.server_push("username", "Carol")模拟后端推送数据，Model 侧的变化同样能触发 View 自动刷新，体现数据流的双向性。

常见误区

误区MVC 就是 View 完全不能读 Model 的数据，两者必须被 Controller 彻底隔开，否则就不算合格的 MVC。

正解传统 Smalltalk MVC 中，View 恰恰会直接订阅 Model 的变化（观察者模式），Controller 只在用户操作介入时才被激活。所谓“隔离”更多是分层职责上的约束，而不是“物理上禁止读取”。就像传统餐厅里，顾客偶尔也能透过出菜窗口看到后厨，但点单仍然必须找服务员。

为何常见：教科书常画一个三角形，省略了 View 到 Model 的订阅虚线，读者便误以为二者绝对不可接触。

误区MVVM 就是把 MVC 的 Controller 改了个名字叫 ViewModel，职责差不多。

正解二者职责重心完全不同。Controller 是“命令分发器”——收到事件后决定调用哪个 Model 方法；ViewModel 是“状态容器”——维护界面需要的状态镜像，并通过数据绑定自动同步。一个是服务员手动跑腿，一个是传送带自动同步，代码组织和心智模型都截然不同。

为何常见：两者类图都是三个框加连线，只看静态结构确实容易混淆，必须结合数据流方向才能区分。

误区Vue 官方文档提过 MVVM，所以 Vue 就是标准 MVVM；React 用组件加事件，所以 React 就是标准 MVC。

正解Vue 并没有一个显式的 ViewModel 类，而是用响应式数据与模板编译实现了“双向绑定”的效果，思想属于 MVVM 但不完全等同。React 更不是标准 MVC，它采用单向数据流与受控组件，事件回调可类比 Controller，但组件本身就同时扮演了 View 与部分 Model 的角色。

为何常见：框架文档为了便于理解会借经典模式做类比，却被读者当成了严格定义。

误区MVVM 的双向绑定一定比 MVC 慢，所以小项目千万别用 MVVM。

正解性能瓶颈通常来自 DOM 操作次数与渲染规模，而非模式本身。MVVM 的依赖收集反而能减少无效渲染，Vue 的虚拟 DOM diff 也比手写 jQuery 的频繁重绘更快。模式影响的是代码组织与可维护性，不是执行效率。换餐厅制度影响的是翻台率和人力成本，并不改变菜本身的味道。

为何常见：把“框架层开销”（Proxy、diff 算法）误当成了“模式固有开销”。

面试题

Q1. 在 MVC 架构中，用户点击按钮后首先由哪一层接收并分发事件？

单选题 · easy

  • A.Model 直接接收按钮事件
  • B.View 来全权处理业务逻辑
  • C.Controller 接收并分发事件← 正确答案
  • D.数据库直接响应处理事件

答案：C。MVC 中 View 只负责展示与捕获手势，事件要交给 Controller 接收并分发给 Model。这就像顾客叫服务员点单，而不是直接冲进后厨。A、D 绕过了控制器，B 则让 View 承担了业务职责，都违背了分层原则。

Q2. MVVM 架构中“双向绑定”指的是哪两者之间的自动同步？

单选题 · easy

  • A.View 与 Model
  • B.Model 与服务器
  • C.Controller 与 View
  • D.View 与 ViewModel← 正确答案

答案：D。MVVM 的双向绑定发生在 View 与 ViewModel 之间：界面的输入会写进 ViewModel，ViewModel 的状态变化也会自动渲染到界面。Model 与服务器只是数据来源，Controller 在 MVVM 中已不存在，因此 A、B、C 都不正确。

Q3. 下列哪种模式通过 Presenter 作为中间层，并手动驱动视图更新？

单选题 · easy

  • A.MVP 架构模式← 正确答案
  • B.MVC 架构模式
  • C.MVVM 架构模式
  • D.模板方法设计模式

答案：A。MVP 用 Presenter 接管所有交互逻辑，数据返回后由 Presenter 调用 View 接口手动刷新，因此选 A。MVVM 靠绑定自动同步，MVC 靠 Controller 分发，模板方法是设计模式而非 UI 架构，均不符合题意。

Q4. React 的核心数据流方向是？

单选题 · mid

  • A.双向绑定同步
  • B.无数据流动机制
  • C.单向数据流← 正确答案
  • D.环形数据流模式

答案：C。React 强调单向数据流：State 通过 render 流向 View，用户操作触发回调后调用 setState 更新 State，再开启新一轮渲染。数据始终沿一个方向闭环流动，而非双向自动同步，所以选 C。

Q5. Vue 中 v-model 指令的本质是下列哪项的语法糖？

单选题 · mid

  • A.通过原生 DOM 直接读取值
  • B.依赖父子组件之间通信
  • C.借助路由参数传递值
  • D.单向绑定结合事件监听实现← 正确答案

答案：D。v-model 等价于 :value 单向绑定加 @input 事件监听：先让数据驱动界面，再通过输入事件把新值写回数据。它不依赖原生 DOM 操作、父子组件通信或路由参数，因此 D 正确。

Q6. 在 MVC 架构中，Controller 的主要职责是什么？

单选题 · mid

  • A.接收输入并更新 Model← 正确答案
  • B.负责渲染最终页面样式
  • C.负责存储全部业务数据
  • D.负责建立数据库连接池

答案：A。Controller 的角色是“服务员”：接收 View 传来的事件，调用 Model 的业务方法更新数据，并在必要时候协调视图刷新。渲染样式是 View 的职责，存储数据是 Model 的职责，数据库连接属于基础设施，均与 Controller 无关。

Q7. 在 MVVM 模式中，若 Model 层数据发生变化，View 如何自动更新？

单选题 · mid

  • A.视图主动轮询数据库刷新
  • B.视图模型感知变化自动同步← 正确答案
  • C.控制器调用渲染方法更新
  • D.用户手动刷新页面内容

答案：B。MVVM 下，Model 变化会被 ViewModel 感知，再通过数据绑定自动推送到 View，开发者无需写手动刷新代码。A 的轮询和 C 的控制器都属于传统模式思维，D 则是主动干预，均不符合 MVVM 的自动同步特征。

Q8. 下列哪些机制常用于实现双向数据绑定？

多选题 · mid

  • A.观察者模式机制← 正确答案
  • B.数据劫持与依赖收集← 正确答案
  • C.脏检查比对机制← 正确答案
  • D.手动事件绑定机制

答案：ABC。观察者模式让视图订阅数据变化，数据劫持（Object.defineProperty/Proxy）配合依赖收集让 Vue 能精确通知，脏检查是 AngularJS 的比对方案，三者都是真实实现手段。D 的“手动事件绑定”只是单向交互，不构成双向自动同步。

Q9. 关于 MVP 与 MVVM 的区别，下列说法正确的有哪些？

多选题 · hard

  • A.二者都要求控制器进行介入
  • B.展示逻辑手动驱动视图更新← 正确答案
  • C.视图模型绑定自动同步视图← 正确答案
  • D.二者都完全隔离视图与模型← 正确答案

答案：BCD。MVP 的 Presenter 通过 View 接口手动刷新界面（B 对），MVVM 靠 ViewModel 绑定自动同步（C 对），两者都让 View 和 Model 不直接交互（D 对）。A 错：MVP 用 Presenter、MVVM 用 ViewModel，都没有 Controller。

Q10. 关于 MVC 与 MVVM 数据流差异，下列哪些说法是正确的？

多选题 · extreme

  • A.MVC 依赖控制器中转更新← 正确答案
  • B.MVVM 依赖绑定机制自动更新← 正确答案
  • C.二者都支持完整的自动双向绑定
  • D.MVC 的视图更新多需手动触发← 正确答案

答案：ABD。MVC 中 Controller 是必经的中转站（A 对），MVVM 通过绑定自动同步（B 对），MVC 的视图更新通常需要手动调用刷新或依赖额外的观察者逻辑（D 对）。C 错：MVC 并不原生支持双向绑定，这是 MVVM 的特征。