一篇文章让你了解 MVC、MVP 、VM

  

  MVC全名是Model--View--Controller，是模型(model)-视图(view)-控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不要重新编写业务逻辑。其中Model层处理数据，业务逻辑等;View层处理界面的显示结果;Controller层起到桥梁的作用，来控制View层和Model层通信以此来达到分离视图显示和业务逻辑层。

  我们往往把Android中界面部分的实现也理解为采用了MVC框架，常常把Activity理解为MVC模式中的Controller。

  Controller执行业务逻辑并且操作Model，但不会直接操作View，可以说它是对View无知的。

  View和Model的同步消息是通过观察者模式进行，而同步操作是由View自己请求Model的数据然后对视图进行更新。

  Controller测试困难。因为视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候， Controller业务逻辑的正确性是无法验证的：Controller更新Model的时候，无法对View的更新操作进行断言。

  View无法组件化。View是强依赖特定的Model的，若需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的

  MVP其实是MVC的一种演进版本，它更简单，将MVC中的Controller改为了Presenter，View通过接口与Presenter进行交互，降低耦合，方便进行单元测试。

  Presenter：作为View与Model交互的中间纽带，处理与用户交互的逻辑。可以把Presenter理解为一个中间层的角色，它接受Model层的数据，并且处理之后传递给View层，还需要处理View层的用户交互等操作。

  View不再负责同步的逻辑，而是由Presenter负责。Presenter中既有业务逻辑也有同步逻辑。

  对比在MVC中，Controller是不能操作View的，View也没提供相应的接口;而在MVP当中，Presenter可以操作View，View需要出示一组对界面操作的接口给Presenter进行调用;Model仍然通过事件广播自己的变更，但由Presenter监听而不是View。

  便于测试。Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。能够最终靠Mock一个View对象，这个对象只要实现了View的接口即可。然后依赖注入到Presenter中，单元测试的时候就可以完整的测试Presenter业务逻辑的正确性。

  View能够直接进行组件化。在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View能做到对业务逻辑完全无知。它只需要出示一系列接口提供给上层操作。这样就可以做高度可复用的View组件。

  MVVM采用双向绑定(data-binding)：View的变动，自动反映在ViewModel，反之亦然，这种模式其实就是框架替应用开发者做了一些工作(相当于ViewModel类是由库帮我们生成的)，开发者只需要较少的代码就能实现很复杂的交互。

  MVVM的调用关系和MVP一样。但是，在ViewModel当中会有一个叫Binder，或者是Data-binding engine的东西。以前全部由Presenter负责的View和Model之间数据同步操作交由给Binder处理。你只需要在View的模版语法当中，指令式地声明View上的显示的内容是和Model的哪一块数据绑定的。当ViewModel对进行Model更新的时候，Binder会自动把数据更新到View上去，当用户对View做相关操作(例如表单输入)，Binder也会自动把数据更新到Model上去。这种方式称为：Two-way data-binding，双向数据绑定。可以简单而不恰当地理解为一个模版引擎，但是会依据数据变更实时渲染。

  MVVM把View和Model的同步逻辑自动化了。以前Presenter负责的View和Model同步不再手动地做相关操作，而是交由框架所提供的Binder进行负责。

  只需要告诉Binder，View显示的数据对应的是Model哪一部分即可。

  提高可维护性。解决了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。

  简化测试。因为同步逻辑是交由Binder做的，View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。大幅度减少了对View同步更新的测试。

  对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。

  数据绑定的声明是指令式地写在View的模版当中的，这一些内容是没办法去打断点debug的。

  MVC模式的通信是单向的，View触发事件或数据的提交，到了Controller做处理逻辑之后，返回Model给View，View再从Model中取出数据，当然View中也会有相应的逻辑。个人觉得这样的描述算得上是比较正确，让我们来看看Cor

  以简洁的API迅速俘获了前端开发者的芳心；MVVM 模型应运而生。控制用户输入，并向模型发送数据。订阅者收到通知后对视图进行一定的更新。

  它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑。

  这两个方向都实现的，我们叫做数据的双向绑定。它们通过ViewModel来通信，ViewModel通常要实现一个observer观察者，当数据发生明显的变化，ViewModel能够监听到数据的这种变化，然后通知到对应的视图做自动更新，而当用户操作视图，ViewM

  在 Vue 的 MVVM 设计中，我们主要是针对Compile，Observer，Watcher，Dep几个部分来实现，核心逻辑流程可参照下图：。为何需要改用proxy，因为defineProperty无法监控到数组下标的变化，导致直接通过数组的下标给数组设

  刚开始接触和使用MVVM模式的时候，就有一种感觉：哇，实现这么一丁点的功能，竟然要写这么多代码，太麻烦了吧！但是后来当我熟悉了这种模式之后，感觉就变成了：哇，还是这么麻烦。不过MVVM设计模式是有它的优点的，不然就不会存在。把界面和业务逻辑分离，这是MVV

  如图，实线代表方法调用，虚线代表事件通知。MVC允许在不改变视图的情况下改变视图对用户输入的响应方式，用户对View的操作交给了Controller处理，在Controller中响应View的事件调用Model的接口对数据来进行操作，一旦Model发生变化便

  Controller控制层触发View层时，并不会更新View层中的数据，View层中的数据是通过监听Model层数据变化而自动更新的，与Controller层无关。View层不能直接访问Model层，必须通过Presenter层提供的接口，然后Prese

  Controller(控制器): 用于连接模型和视图控制应用程序的流程,通常控制器负责响应View的事件，调用Model的接口做相关操作;Controller会对来自View数据来进行预处理并决定调用Model的相关暴露接口;View收到通知后从Model请求

  在Android开发中使用MVP和MVVM模式早已不是新鲜事了，各种MVP/MVVM相关的文章、开源库也已屡见不鲜，甚至是让人眼花撩乱，那么我为什么还要在这个早已被画满涂鸦的黑板上再来涂涂画画呢?是想彰显我的存在感吗?我还想要警醒读到这篇文章的各位：你们对

  组件化和插件化已经提出了很久了，到现在非常稳定的一种架构方案了，在三年前，组件化和插件提出来没多久，前公司就已经在项目中使用了，只是当时还只是菜鸟，没有资格参与到架构的建设中，只是在大佬搭好的架构中写一些业务代码。当时的做法基本上也和现在网上流行的大多

  WPF 利用附加属性创建FreezableCollection集合和反射实现控件参数以MVVM模式传递

  本文中的例子本质上是利用附加属性传递附加对象，并在观察者模式中使用反射技术实现指定名称的事件参数传递。本文中框架任然有很多问题，目前来说是勉强能用，有可以修改的地方尽管说！创建附加属性时写DependencyProperty的这一部分 ，并且需要用Se