3分钟理解透 MVC / MVP / MVVM 异同

MVC MVVM 和 MVP 这几种模式在现在的主流框架中被广泛应用，那他们有什么区别呢？
 

# MVC

  MVC，即Model View Controller，是比较直观的架构模式，分有以下几个步骤：

【MVC的工作流程】
  用户触发事件 -> View（负责接收用户的输入操作） -> Controller（处理用户事件逻辑） -> Model（持久化存储数据收到更新请示） -> View（更新数据反馈给用户）

【典型框架】Backbone，Spring

【补充】React并不是一个MVC框架，而是一个用于构建组件化UI的库，是一个前端界面开发工具。所以顶多算是MVC中的V（view）

  图例展示如下：

  值得注意的是，这些 通信都是单向的。用户也可以通过改变url来触发 hashChange事件，这里不多说。

【MVC特点】Controller很薄，基本上只起到路由作用，作为用户逻辑信息传递使用。而因为View需要接收Model层传来 View 层非常厚，含有大量业务逻辑。
  在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包含一些业务逻辑。在MVC里，更关注的是Model的不变，而同时有多个对Model的不同显示，即View。所以，在MVC中，Model不依赖于View，但是View依赖于Model，这也是造成数据单向的原因。另外，因为有些业务逻辑在View中实现，导致了更改View也比较困难。

  虽然View 访问Model并没有错，但是我们依旧不建议在View中依赖Model，而是尽可能的将业务逻辑都放到Controller中。
 

# MVP

  MVP，即Model View Presenter，将MVC中的 Controller 更改为 Presenter (提供者)，目的是为了切断 Model 和 View 之间的关系，由 Presenter 充当桥梁，实现 View 和 Model 的完全通信。这样，就可以把业务逻辑挪到 Presenter上, 减轻View承载的任务，提高视图响应速度

【典型框架】Riot

  图例展示如下

【MVP特点】Presenter完全的把View和Model进行分离，主要的业务逻辑都在Presenter里实现。而且具体的View与Presenter并没有直接关联，而是通过定义好的一些接口进行交互，从而是的在变更或更新View的时候Presenter能够保持不变，达到了重用业务逻辑的目的。
  在MVP中，View是很薄的一层，它只需要把信息显示清除就可以了，后期维护中，可以根据需要随便的修改View而不需要考虑Presenter的感受。如果页面信息（UI）较为复杂，而且相关显示信息和Model有关，则可以在View 和Presenter之间放置一个 Adapter ，在Riot中就提供了update()方法，以便提供开发人员在需要时更新页面数据。
  在MVP模式里，View只应该有简单的Set/Get 方法，用于用户输入和设置页面显示内容，除此之外就不该有更多内容，绝不允许直接访问Model。

  另外，我们还能够编写提供给测试用的View，来模拟用户的各种操作，从而实现对Presenter的测试，而不需要使用自动化测试工具。

【MVP优势】
1、 模型与视图完全分离，我们可以修改视图而不影响模型
2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部
3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）

【MVP缺点】由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁；如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。
 

# MVVM

  MVVM，即 Model View ViewModel，他本质上是MVC的改进版。相比于MVP，其实只是把Presenter改成为ViewModel，基本上说后两者大同小异，唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。

【典型框架】Angular，Vue，Ember

  图例展示如下:

  将数据绑定与Presenter Model 相结合是非常好的一种策略，这使得开发人员能将View和逻辑分离出来，而且这种技术也非常简单实用。它与MVP非常的相似，除了你需要为View量身定制一个Model，也就是ViewModel。它包含了所有由UI特定的接口和属性，并由一个 ViewModel 的视图的绑定属性，并可获得二者之间的松散耦合，所以需要在ViewModel 直接更新视图中编写相应代码。

【MVVM优点】
  MVVM模式和MVC模式一样，主要目的是分离 视图（View）和模型（Model），有几大优点

1. 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的View上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
3. 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xml代码。
4. 可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。
    

# mvc,mvp,mvvm三者演化

# 后语

  或许你常听到有人说，你怎么还在用MVC这种垃圾模式，我早就在用MVVM了。其实，任何的框架，都是为了项目而服务的，没有绝对的好坏之分，只有更合适的选择。一个框架的选择，要综合考虑项目阶段，团队规模及整体能力等条件，切莫为了设计而设计，为了框架而框架。