共计 1580 个字符，预计需要花费 4 分钟才能阅读完成。
MVC、MVP 和 MVVM
三个非常重要的架构模式
MVC (Model(模型)-View(视图)-Controller(控制器))
MVP (Model(模型)-View(视图)-Presenter(中介者))
MVVM (Model(模型)-View(视图)-ViewModel(视图模型))
MVC 模式
MVC 是一个架构设计模式，它通过分离关注点的方式来支持改进应用组织方式。它促成了业务数据 (Models) 从用户界面 (Views) 中分离出来，还有第三个组成部分 (Controllers) 负责管理传统意义上的业务逻辑和用户输入。
Models
Models 管理一个业务应的数据。它们既与用户界面无关也与表现层无关，相反的它们代表了一个业务应用所需要的形式唯一的数据。当一个 model 改变时 (比如当它被更新时)，它通常会通知它的观察者(比如我们很快会介绍的 views) 一个改变已经发生了，以便观察者采取相应的反应。
Views
视图是模型的可视化表示，提供了一个当前状态的经过过滤的视图。JavaScript 的视图是关于构建和操作 DOM 元素的。
一个视图通常是模型的观察者，当模型改变的时候，视图得到通知，因此使得视图可以更新自身。
Controller
控制器是模型和视图之间的中介，典型的职责是当用户操作视图的时候同步更新模型。
MVC 模式的优势
有利于对应用程序中功能进行更加简单的模块化。
整体的维护更加便利，控制器修改数据，数据驱动视图。
模型与视图解耦，编写单元测试更方便。
底层模型和控制器的代码解耦，可复用。
分离应用程序的体积和角色，允许负责核心逻辑的开发者和工作于用户界面的开发者同时进行工作。
MVP 模式
模型 - 视图 - 展示器 (MVP) 是 MVC 设计模式的一个衍生模式，它专注于提升展现逻辑。
Presenter
MVP 中的 P 代表展示器。它是一个包含视图的用户界面逻辑的组件。不像 MVC，来自视图的调用被委派给了控制器，它是从视图中解耦出来的，并且转而通过一个接口来同它进行对话。
在 MVP 中，P 观察着模型并且当模型发生改变的时候对视图进行更新（被动视图）。P 切实的将模型绑定到了视图，这一责任在 MVC 中被控制器提前持有了。
MVC 模式的优劣
相较于 MVC 模式，MVP 的好处在于：
增强应用的可测试性
更加干净的隔离视图和模型
劣势在于：
缺乏数据绑定支持
MVVM 模式
MVVM(Model View ViewModel)是一种基于 MVC 和 MVP 的架构模式，它试图将用户界面（UI）从业务逻辑和行为中更加清晰地分离出来。为了这个目的，很多例子使用声明变量绑定来把 View 层的工作从其他层分离出来。
][3]
ViewModel
视图模型被认为是一个专门进行数据转换的控制器。它可以把对象信息转换到视图信息，将命令从视图携带到对象。
视图模型位于我们 UI 层后面层。它通过视图发布对象的公共数据，同时它作为视图源提供数据和方法。
视图和视图模型使用数据绑定和事件进行通信。视图模型不仅仅发布对象属性，它还提供其他的方法和特性，诸如验证。
我们的视图处理自己的用户接口事件，并会把相关事件映射到视图模型。对象和它属性与视图模型是同步的，且通过双向数据绑定进行更新。
触发器（数据触发器）允许我们进一步在视图状态变化后改变我们的对象属性。
MVVM 模式优劣
优点：
MVVM 更加便于 UI 和驱动 UI 的构造块, 这两部分的并行开发
抽象视图使得背后所需要的业务逻辑 (或者粘合剂) 的代码数量得以减少
视图模型比事件驱动代码更加容易进行单元测试
视图模型 (比视图更加像是模型) 能够在不用担心 UI 自动化和交互的前提下被测试
缺点：
对于更简单的 UI 而言,MVVM 可能矫枉过正了
虽然数据绑定可以是声明性质的并且工作得很好，但在我们简单设置断点的地方，它们比当务之急的代码更加难于调试
在大型的应用程序中，将视图模型的设计提升到获取足够所需数量的泛化，会变得更加的困难
