引言

随着近些年MVP在Android上的火热，如今各种关于MVP的文章已经满天飞，由于各自的业务场景以及开发者自身的理解，MVP的使用方式是各不相同，各种复杂和混乱的文章导致Android初学者始终难以正确的在自己的项目中使用MVP，所以笔者写下了这篇文章。在学习MVP之前，我们首先要先了解其历史。

MVC

对于MVP (Model View Presenter)架构是从著名的MVC(Model View Controller)架构演变而来的。MVC概念最早源于1979年，其中Model表示模型，单独的对象或对象的结构，View是Model的可见表示，Controller为用户和系统之间的连接。而对于Android应用的开发中本身可视为一种MVC架构。通常在开发中将XML文件视为MVC中的View角色，而将Activity则视为MVC中的Controller角色。不过更多情况下在实际应用开发中Activity不能够完全充当Controller，而是Controller和View的合体。于是Activity既要负责视图的显示，又要负责对业务逻辑的处理。这样在Activity中代码达到上千行，甚至几千行都不足为其，同时这样的Activity也显得臃肿不堪。所以对于MVC架构并不很合适运用于Android的开发中。下面就来介绍一下MVP架构。

MVP

对于一个应用而言我们需要对它抽象出各个层面，而在MVP的UI架构模式中它将UI界面和数据进行隔离，所以我们的应用也就分为三个层次。

View: 对于View层也是视图层，在View层中只负责对数据的展示，提供友好的界面与用户进行交互。在Android开发中通常将Activity或者Fragment作为View层。
Model: 对于Model层也是数据层。它区别于MVC架构中的Model，在这里不仅仅只是数据模型。在MVP架构中Model它负责对数据的存取操作，例如对数据库的读写，网络的数据的请求等。
Presenter:对于Presenter层他是连接View层与Model层的桥梁并对业务逻辑进行处理。在MVP架构中Model与View无法直接进行交互。所以在Presenter层它会从Model层获得所需要的数据，进行一些适当的处理后交由View层进行显示。这样通过Presenter将View与Model进行隔离，使得View和Model之间不存在耦合，同时也将业务逻辑从View中抽离。

因此，MVP是一个非常好的解耦架构模式。下面我们来看一下google官方给出的这个todo-mvp的MVP架构示例。

项目结构分析

项目的目录结构

它的目录结构是按模块的功能来划分。基本上每个模块下都有Activity，Contract，Fragment，Presenter这四个主要的类。接下来我就选取其中addedittask这个模块进行分析和讲解。

首先我先讲一下AddEditTaskContract这个类，Contract,中文意思就是契约，这里面规定了这个模块的所有业务逻辑。规定了View和Presenter的接口。MVP的V层和P层都用这个类规范了。让整个业务逻辑更加的清晰明确。下面贴出其代码。

View

由上图就可以看到，View 这个接口就是规定了UI显示的业务逻辑，这个模块的UI有什么逻辑就一目了然了。

Presenter

AddEditTaskPresenter

在这个AddEditTaskPresenter的类中，就实现了AddEditTaskContract.Presenter这个接口，注意上面的注释，其实已经给我们解释了这个类是做什么用的了。监听用户在UI上的动作，接收数据和更新请求的UI。实现了那个接口的话，类中就会重写那些接口定义好的方法。你只要把每个方法该实现的逻辑写在方法里就好了。

到这里有的人可能会问，怎么没看到Model层呢？
首先，我们复习一下，Model层是干什么的呢？Model层不仅仅是数据模型，还负责对数据的存取操作，例如对数据库的读写，网络的数据的请求等。那么在谷歌这个todo-mvp中把Model层放在data这个文件夹中。

data文件夹目录

之后就是V层的使用了。在Fragment这个实际操作显示的类中，实现View的回调，控制View的显示。再在这里实例化presenter，调用presenter处理好的逻辑在相应的UI逻辑方法中使用。如下图

Fragment

而这里Activity这个类也只是起承载Fragment和传一些必要的值和对象给Fragment的作用而已。

Activity