Android -------- MVC，MVP 和 MVVM 架构设计模式

MVC（Model-View-Controller）是最常见的软件架构之一，业界有着广泛应用。它本身很容易理解，但是要讲清楚，它与衍生的 MVP 和 MVVM 架构的区别就不容易了。

一、MVC

MVC模式的意思是，软件可以分成三个部分。

• 视图（View）：用户界面。
• 控制器（Controller）：业务逻辑
• 模型（Model）：数据保存

各部分之间的通信方式如下。

1. View 传送指令到 Controller
2. Controller 完成业务逻辑后，要求 Model 改变状态
3. Model 将新的数据发送到 View，用户得到反馈

所有通信都是单向的。

MVC优点：

• 耦合性低
• 重用性高
• 生命周期成本低
• 部署快
• 可维护性高
• 有利软件工程化管理

MVC缺点：

• 没有明确的定义
• 不适合小型，中等规模的应用程序
• 增加系统结构和实现的复杂性
• 视图与控制器间的过于紧密的连接
• 视图对模型数据的低效率访问
• 一般高级的界面工具或构造器不支持模式

在MVC里，View是可以直接访问Model的。从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。

所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的

二、MVP

MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。

1. 各部分之间的通信，都是双向的。

2. View 与 Model 不发生联系，都通过 Presenter 传递。

3. View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。

MVP优点：

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

MVP缺点：

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

MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责视图。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller

三、MVVM

MVVM是Model-View-ViewModel的简写，这个模式提供对View和View Model的双向数据绑定，使得View Model的状态改变可以自动传递给View

• Model：数据层，负责处理数据的加载或者存储
• View：视图层，负责界面数据的展示，与用户进行交互
• ViewModel：负责完成View于Model间的交互,负责业务逻辑

来自： http://www.ruanyifeng.com/blog/2015/02/mvcmvp_mvvm.html