MVC,MVP和MVVM架构模式都是为了解决图形界面应用程序复杂性管理问题而产生的应用架构模式。

图形界面的应用程序会提供用户可视化的界面，用户可以基于这个界面进行操作，程序根据用户的操作做出对应的响应(如页面的滑动，数据的更新等)，为了更好的管理应用程序的复杂性，在开发图形界面应用程序我们将展示给用户的图形界面称为View，应用程序的数据称为Model(Model对应用程序的业务逻辑无感知，只保存数据和对外提供数据和更新数据的接口)，而根据为了解决响应用户操作的业务逻辑的管理和View与Model的数据同步问题的方式区分了MVC,MVP和MVVM

MVC

MVC架构模式使用Controller来响应用户操作的业务逻辑的管理和View与Model的数据同步

Controller和View都依赖Model层，Controller和View可以互相依赖

当用户对View层进行操作后(比如点击了一个按钮)，Controller捕获这个操作并执行对应的操作，所进行的操作可能需要对Model层进行操作，当Model的数据发生更改后，会通过观察者模式通知View，View会向Model请求最新的数据并重新更新界面

如下图：

需要特别注意的是MVC模式的精髓在于第三点：Model的更新是通过观察者模式告知View的.通过观察者模式的好处就是：不同的MVC三角关系可能会有共同的Model，一个MVC三角中的Controller操作了Model以后，两个MVC三角的View都会接受到通知，然后更新自己。保持了依赖同一块Model的不同View显示数据的实时性和准确性。

MVC的优缺点：

优点：

1、把业务逻辑全部分离到Controller中，模块化程度高。当业务逻辑变更的时候，不需要变更View和Model，只需要Controller换成另外一个Controller就行了。
2、观察者模式可以做到多视图同时更新。

缺点：

1、Controller测试困难。因为视图同步操作是由View自己执行，而View只能在有UI的环境下运行。在没有UI环境下对Controller进行单元测试的时候，Controller业务逻辑的正确性是无法验证的：Controller更新Model的时候，无法对View的更新操作进行断言。
2、View无法组件化。View是强依赖特定的Model的，如果需要把这个View抽出来作为一个另外一个应用程序可复用的组件就困难了。因为不同程序的的Domain Model是不一样的

MVP

MVP模式把MVC模式中的Controller换成了Presenter。MVP层次之间的依赖关系如下：

可以看到相对MVC模式MVP模式View和Model之间的依赖关系没有了，其它的依赖关系的是类似的

和MVC模式一样，用户的对View的操作会被捕获并交由Presenter进行具体的逻辑操作，但如果Model发生了变化并不会通知View，而是通知Presenter，Presenter再通过View提供给Presenter的接口对View的视图进行更改

MVP的优缺点：

优点：

1、便于测试。Presenter对View是通过接口进行，在对Presenter进行不依赖UI环境的单元测试的时候。可以通过Mock一个View对象，这个对象只需要实现了View的接口即可。然后依赖注入到Presenter中，单元测试的时候就可以完整的测试Presenter业务逻辑的正确性。
2、View可以进行组件化。在MVP当中，View不依赖Model。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务逻辑完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做高度可复用的View组件。

缺点：

1、Presenter中除了业务逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。

MVVM

MVVM的依赖关系与MVP的依赖关系相同

MMVM的调用关系也和MVP相同。但是，在ViewModel当中会有一个叫Binder，或者是Data-binding engine的东西。以前全部由Presenter负责的View和Model之间数据同步操作交由给Binder处理(在Android开发中使用DataBinding框架可以实现)。当ViewModel对进行Model更新的时候，Binder会自动把数据更新到View上去，当用户对View进行操作（例如表单输入），Binder也会自动把数据更新到Model上去。这种方式称为双向数据绑定。

MVVM的优缺点：

优点：

1、提高可维护性。解决了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。
2、简化测试。因为同步逻辑是交由Binder做的，View跟着Model同时变更，所以只需要保证Model的正确性，View就正确。大大减少了对View同步更新的测试。

缺点：

1、过于简单的图形界面不适用，或说牛刀杀鸡。
2、对于大型的图形应用程序，视图状态较多，ViewModel的构建和维护的成本都会比较高。
3、数据绑定的声明是指令式地写在View的模版当中的，这些内容是没办法去打断点debug的。