表现层模式是什么
MVC、MVP 与 MVVM 是三种经典的表现层模式，区别在于视图与逻辑的耦合方式与数据流方向。MVC 由控制器接收输入、更新模型、由模型驱动视图刷新；MVP 引入呈现器，视图被动、逻辑集中在呈现器，便于单元测试；MVVM 通过数据绑定把视图模型的状态自动同步到视图，前端框架广泛采用。三者共同的目标是让业务逻辑不写在视图层，视图可替换。
对比
| 模式 | 核心角色 | 数据流 | 典型场景 |
|---|---|---|---|
| MVC | 模型-视图-控制器 | 输入经控制器到模型，模型通知视图 | 服务端 Web 框架 |
| MVP | 模型-视图-呈现器 | 视图把事件交给呈现器，呈现器操作视图接口 | 测试要求高的桌面与移动端 |
| MVVM | 模型-视图-视图模型 | 双向绑定自动同步视图与视图模型 | 带数据绑定的前端框架 |
基本信息
| 共同目标 | 业务逻辑不写在视图层，视图可替换、可测试 |
|---|---|
| 选择依据 | 框架约束与测试策略，而不是个人偏好 |
| 常见误区 | 控制器或视图模型里堆积业务规则与数据访问 |
| 测试策略 | 逻辑集中在可控单元中，用单元测试覆盖，界面部分交给端到端测试 |
| 适用范围 | 有界面交互的应用；纯接口服务通常不需要表现层模式 |
典型使用场景
- 服务端页面应用：用 MVC 组织请求处理与视图渲染
- 复杂交互前端：用 MVVM 把状态与界面绑定分离，减少手动操作 DOM
- 需要高测试覆盖的客户端：用 MVP 让逻辑脱离视图单独测试
- 多端复用逻辑：把业务逻辑提取到视图模型或呈现器，多端共享
- 遗留界面重构：先抽离逻辑单元，再逐步替换视图实现
- 表单密集型应用：视图模型承担校验与状态组织
模式选择受框架约束：使用带数据绑定的框架时按 MVVM 组织代码，使用传统服务端框架时按 MVC 组织，强行混用会增加复杂度。
视图模型直接依赖具体网络客户端与存储实现，会让逻辑单元重新变得难以测试，应通过接口注入。