Android MVP 架构

在android开发中，我们不外乎这三种架构：MVC，MVP，MVVM

• 1 MVC

MVC的经典架构如下：

MVC简单的来说就是通过Controller去操作Model层，同时去更新View层显示。另外View层也会与Model层有交互。造成这三者之间的耦合比较大。
比如我们在平常的Android开发中，View层就是xml文件以及各种控件，Controller角色由我们的Activity或者Fragment扮演，而model层就是各种数据及其封装了，我们在开发中一般来说是这样做得：

Activity或者Fragment： 初始化各种View，设置各种View的显示及绑定事件，加载Model层数据，根据各个控件的点击等动作，完成各个界面逻辑的炒作等，比如跳转界面，更改View显示等。
View: 控件事件处理，例如点击事件中做逻辑操作，一般需要更新Model层数据;控件更新显示等
Model： 数据的进一步处理，例如校验，组装，更改，以及对上层的封装等。
我们发现作为Controller的职责是在太多，而对某个View来说，也可以直接更新Model层，这就造成了Controller的代码量很大，我曾见过在项目中，一个Activity的代码量达到了2000多行的。这样的工程既不利于后期维护，也不利于测试。实在不是一个明智的选择。

• 2 MVP

作为一个MVC的改良版，MVP的结构如下：

View：主要负责界面的显示及跟数据无关的逻辑，比如设置控件的点击事件等
Presenter:主要负责View与Model的交互
Model:数据部分

MVP很好的解决了View层与Model层的分离，使之交互都是通过Presenter层来做，这样做得好处有以下几点：

1 便于单元测试，因为对于Model层或者Presenter来说，都是一些接口，便于编写测试用例
2 维护性提高，对于View层来说的改动不影响Presenter和Model层的改动。

最主要的好处就是以上两点，坏处也有以下几点：

1 代码量增加，特别是需要新增加View与Presenter，及Presenter类
2 View与 Presenter的交互的接口的粒度不好把握，这个需要深入的理解业务才能好好解决。

MVP的核心是：
View层不持有Model层对象任何引用，当然参数里面和临时变量里可以有Model层对象，只持有Presenter层对象引用，任何需要更新或者操作数据的，都间接通过Presenter对象去操作数据。而Model层想要操作View层是无法实现的，必须通过Presenter层。

Presenter层持有View层对象的引用，除此之外不持有其他的UI控件等的引用，Model层会把想要更新View的操作委托Presenter去操作，而Presenter层会把更新View操作交给View层对象去操作。