Android 中 MVC 、MVP 、MVVM 模式

软件的架构方式很多，从MVC，到MVP，再到MVVM，在不断演化的过程中核心的思想就是模块内部的高聚合和模块之间的低耦合。从而提高程序的开发效率，并且更容易进行后续的测试以及定位问题。

一、MVC模式(Model, View, Controller)

模型层(Model)
负责处理数据的加载或者存储，封装与应用程序的业务逻辑相关的数据以及对数据的处理。
视图层(View)
负责数据的展示，与用户交互。
控制层(Controller)
Controller 是一个桥梁的作用，它负责把View的请求转发给 Model,在把 Model 处理结束的消息通知 View。

优点：

• 耦合性低
• 开发效率高
• 可维护性高

• 易于理解

  缺点：

• View 和 Model 之间直接进行交互，意味着两层之间存在耦合

• Model 难以符合复杂多变的View端变化，导致 Model 的作用变小，造成Controller 既要承载 View 处理 UI 视图变化，又要处理业务逻辑，Controller 会变得臃肿，耦合度变高，后期维护比较困难。

二、MVP（Model, View, Presenter）

使用 Presenter 来代替 Controller ,而且改变了数据的流向，View 和 Model 之间不能直接进行交互，而是通过 Presenter 传递。
在 MVP 中，Presenter 同时持有 View 和Model，View 和 Model 也持有对Presenter 的引用。当 View 中的视图改变，需要更新数据时，通过 Presenter 来通知 Model 更新数据；当数据发生改变时，也通过其自身含有的 Presenter 引用来通知 View 来进行更新。这样 Presenter 就可以作为桥梁来联系两者，而传统的 Activity 只需要进行 UI 绘制展示即可。
MVP 使整个软件分层清晰，降低耦合度，也将 Activity 从即是 Controller 又是View 的境地解脱出来，只需要负责 UI 即可；但加入了 Presenter 作为 View 和 Medel 的桥梁，会导致 Presenter 变得臃肿，而且对于每一个 Activity，基本上都需要一个对应的 Presenter 来进行对应。

模型层(Model)
负责处理数据的加载或者存储，封装与应用程序的业务逻辑相关的数据以及对数据的处理。
视图层(View)
负责数据的展示，与用户交互。

中间者(Presenter)
Model 和 View 之间的桥梁，绑定 Model 和 View

优点

• Model 与 View 完全分离，修改 View 不会影响 Model
• 可以更高效的使用 Model，因为所以的交互到在 Presenter 里
• 一个 Presenter 可以用于多个 View,而不需要改变 Presenter 的逻辑，View 的变化比 Model 的变化频繁( Presenter 的复用)
• View 可以进行组件化，MVP 中，View 不依赖 Model。(View的复用)

缺点

• View 和 Presenter 的交互比较频繁，修改 View 的时候，Presenter 也要跟着修改
• Presenter 中除了业务逻辑外，还有 View -> Model，Model -> View 手动同步逻辑，造成 Presenter 比较笨重，维护比较困难。

三、MVVM

在 MVVM 中，一个 ViewMode 和 一个 View 匹配，没有 MVP 的 IView 接口，而是和 View 绑定，所以 View 中的修改变化，都会更新到 ViewModel 中，同时ViewModel 的任何变化也会自动同步到 View上显示。
MVVM 中出现 DtataBinding ，在 XML 中进行数据绑定，增加 XML 重量，不再仅仅是布局，均衡了各部分的职责。

优点

• 解决了 MVP 大量的手动 View 和 Model 同步的问题，提供双向绑定机制，提高代码可维护性。
• 响应式编程更方便。

缺点

• 过于简单的界面大才小用。
• 视图状态较多，ViewModel 的构建和维护成本比较高。
• 数据绑定的声明写在 View 的模板中，这些内容没办法 debug。

MVVM 是从 MVP 进一步的发展与规范，MVP 隔离了 MVC 中 Model 和 View 的直接联系，靠 Presenter 来中转，所以使用 MVP 时 Presenter 是直接调用View 的接口来实现对视图的操作的，这个 View 接口一般来说是 showData、showLoading 等。Model 和 View 隔离，方便测试，但代码不够简洁优雅，所以MVVM 就弥补这些缺陷。在 MVVM 中出现 DataBinding，View 接口的showData 等实现方法就可以用 Binding 来实现。

如果把三者放在一起比较，那么三者的共同点也就是Model和View

• Model: 提供对应用程序数据操作的接口，也可以在数据变化的时候发出通知。Model 不依赖于 View 的实现，外部程序调用 Model 的接口就可以实现对数据的增删改成。
• View: 对用户的交互操作，包括UI展示和一些相关的界面逻辑代码。

三者的差异在于如何粘合 View 和 Model,实现用户的加护操作以及变更通知

• Controller
  Controller 接收View的操作事件，根据事件不同，调用 Model 的接口进行数据操作，或者进行 View 跳转，从而意味着一个 Controller 可以对应多个 View。Controller 对 View 的实现不太关心，只会被动的接收，Model 的数据变更不通过 Controller 直接通知 View,通常 View 采用观察者模式监听 Model 的变化。

• Presenter
  Presenter 和 Controller 一样，接收 View 的命令，对 Model 进行操作；与Controller 不同的是 Presenter 会反作用于 View, Model 的变更通知首先被Presenter 获得，然后 Presenter 再去更新 View ,一个 Presenter 只对应一个View。

• ViewModel
  ViewModel 关键在于数据绑定(Databinding) , View的变化会直接影响 ViewModel , ViewModel 的变化或者内容也直接体现再 View 上。这种模式实际上是框架替开发者做了一些工作，开发者只需要较少的代码就可以实现比较复杂的交互。