MVC、MVP、MVVM联系和区别
MVC、MVP、MVVM 这些模式是为了解决开发过程中的实际问题而提出来的，目前作为主流的几种架构模式而被广泛使用。
MVC
MVC（Model-View-Controller） 是表现层的框架模式，用于解除业务逻辑和视图之间的耦合，从而易于扩展，便于测试。
MVC 模式认为软件可以分成三个部分。
- 视图（View）：用户界面。
- 控制器（Controller）：业务逻辑
- 模型（Model）：数据保存
用户操作->View（负责接收用户的输入操作）->Controller（业务逻辑处理）->Model（数据持久化）->View（将结果反馈给 View）。
优点：
- 分层，结构清晰，耦合性低，大型项目代码的复用性得到极大的提高.
- 开发人员分工明确，提高了开发的效率，维护方便，降低了维护成本。
缺点：
- 增加了系统结构和实现的复杂性
- 视图与控制器间的过于紧密的连接
- 视图对模型数据的低效率访问
- 目前一般高级的界面工具或构造器不支持 MVC 模式
MVP
MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。目的就是为了完全切断 View 跟 Model 之间的联系，由 Presenter 充当桥梁，做到 View-Model 之间通信的完全隔离.
主要的特点是：
- 各部分之间的通信，都是双向的。
- View 与 Model 不发生联系，都通过 Presenter 传递。
- View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而 Presenter 非常厚，所有逻辑都部署在那里。
优点：
便于测试。Presenter 对 View 是通过接口进行，在对 Presenter 进行不依赖 UI 环境的单元测试的时候。可以通过 Mock 一个 View 对象，这个对象只需要实现了 View 的接口即可。然后依赖注入到 Presenter 中，单元测试的时候就可以完整的测试 Presenter 业务逻辑的正确性。这里根据上面的例子给出了 Presenter 的单元测试样例。
View 可以进行组件化。在 MVP 当中，View 不依赖 Model。这样就可以让 View 从特定的业务场景中脱离出来，可以说 View 可以做到对业务逻辑完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做高度可复用的 View 组件。
缺点：
- Presenter 中除了业务逻辑以外，还有大量的 View->Model，Model->View 的手动同步逻辑，造成 Presenter 比较笨重，维护起来会比较困难。
MVVM
MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。
唯一的区别是，它采用双向绑定（data-binding）：View 的变动，自动反映在 ViewModel，反之亦然。Angular 和 Ember 都采用这种模式。
典型的应用有.NET 的 WPF，js 框架 Knockout、AngularJS 、Vue 等。
优点：
- 提高可维护性。解决了 MVP 大量的手动 View 和 Model 同步的问题，提供双向绑定机制。提高了代码的可维护性。
- 简化测试。因为同步逻辑是交由 Binder 做的，View 跟着 Model 同时变更，所以只需要保证 Model 的正确性，View 就正确。大大减少了对 View 同步更新的测试。
缺点：
- 过于简单的图形界面不适用，或说牛刀杀鸡。
- 对于大型的图形应用程序，视图状态较多，ViewModel 的构建和维护的成本都会比较高。
- 数据绑定的声明是指令式地写在 View 的模版当中的，这些内容是没办法去打断点 debug 的。
参考资料
http://www.ruanyifeng.com/blog/2015/02/mvcmvp_mvvm.html
https://www.jianshu.com/p/6a86f7fdc0cb