[譯]: 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 等).