[译]: MVC, MVP 和 MVVM 模式的对比

原文: http://www.andyfrench.info/2010/07/comparing-mvc-mvp-and-mvvm-patterns...

译注: 这篇文章提到的模式应该主要指的微软旗下图形界面技术的模式.

最近看了一些技术演讲, 觉得自己应该储备一下常引用到的一些设计模式.

Silverlight 和 WPF 经常关联 Model-View-ViewModel (MVVM) 模式,
(见框架比如: Prism, MVVM Light, Caliburn 等)

ASP.Net MVC 当然运用了 Model-View-Controller.
以前我还用 Model-View-Presenter (MVP) 的变种来解决 ASP.Net Web Forms 一些短板.

每个框架都在尝试解决这样一些问题:

1. 在哪里? 怎样? 去维护 UI 当中的状态?
2. 业务逻辑在应用的什么地方? 怎样被调用?
3. 怎样保证 UI 跟数据的改变同步? 还有 UI 元素之间相互同步?
4. 怎样保证对我们关心的代码做分离, 来降低可测试代码的耦合?

问题在于, 它们对比是怎样?

Note: There are variations on the theme here so there may be alternatives especially with MVP (e.g. Passive View, Supervising Controller, Front Controller).

注意: 现在的场景当中会有很多的变种的方案, 特别是 MVP,
(比如 Passive View, Supervising Controller, Front Controller)

MVC

Input 被引导到 Controller.

Controller 决定渲染哪个 View, 并且生成 View 对应的 Model.

一个 Controller 可以从很多个 View 当中选择一个渲染.

View 没有他的 Controller 的信息.

业务逻辑存在于 Controller 当中.

当多个用户请求之间(基于 HTTP, 无状态的协议), 状态不能被维护的情况下, MVC 是有用的.

MVP

Input 被引导到 View.

往往是在 View 抛出一个事件时, 作为响应, Presenter 对 View 进行更新.

State 被高效地存储在 View 当中.

业务逻辑存在于 Presenter.

MVVM

Input 被引导到 View.

View 只知道 ViewModel, 不知道其他的信息.

ViewModel 只知道 Model, 不知道其他的信息.

View 从 ViewModel 获取数据, 而不是直接从 Model. 这通常通过数据绑定实现.

State 跟业务逻辑存在于 ViewModel.

ViewModel 可以被认为是 UI 的抽象表示.

State 可以在多个用户请求能被维护的情况下会很有用(比如 Silverlight, WPF 等).