mvp架构解析

MVP现在已经是目前最火的架构，很多的框架都是以MVP为基础，甚至于Google自己都出一个MVP的开源架构。https://github.com/googlesamples/android-architecture，里面有好几个项目，我们先谈下todo-mvp这个最基础的MVP架构。

说到MVP，我们不得不谈到最最经典的MVC架构。什么是MVC，概括来说就是数据层，控制层以及显示层的分离。虽然我们可以把所有的代码都写在一个类里，但是作为了一个优秀的程序员你我想一定不会这样做，所以我们想到了解耦，解耦也是扩展性，可测性以及可维护性的基础。那么最简单也最通用的解耦就是分层，根据调用关系从上而下或是根据业务的特性，从业务功能分层实现。如jsp+severlet+db的mvc结构就是按照从上到下划分的。Jsp是用于显示，serverlet是业务控制，db是数据层。MVC的层级结构如下：

Controller响应用户的操作事件，以及对请求事件的转发和处理。在事件的处理和转发过程中会操作Model，对Model进行必要的增，删，改，查等一系列单一或是组合处理。而Model是在经过Controller的操作后，让View根据Model刷新自己的状态，从而呈现给用户，但是Model是不能直接通知View的，一定要通过Controller 。这个是一个完整的MVC流程。简易交互如下：

而在android里对应的mvc结构是：V可以理解为控件，C是activity，M是数据。 如果M的变化要通知到V，只能走： M->C->V,这条路径也就是上图的体现，这比较常用的，但这种交互有个缺点，就是会导致C很复杂：C作为Activity要进行业务逻辑处理，要控制V的现实逻辑，同时还要做好告知V数据变化的任务。这样会导致一个角色具有多种功能，这在架构中是很不好的一种表现方式，会使得这个模块代码行数多，逻辑复杂，不可测，扩展性差等问题。

为了使得C的功能尽量单一化，所以我们就引入了MVP模式（个人看法），这个P是什么，可以把P看成是一个三角菱镜，放在了上面的交互中间，所以MVP的交互可以看成：

图中红色部分就为P.蓝色为原来MVC的调用路线，黑色为MVP的调用路线。通过P的引入，会最大化的释放C的功能，使得C功能单一化，把业务逻辑处理和告知V数据变化等功能分离给P来处理。这样C的功能更多的是初始化P,V,M三则之间的关系。

我们来分析下todo-mvp(我们只是从架构层次去分析，不是从业务或是代码逻辑分析)：下面是todo-mvp一个功能addedittask的UML图（用的是Gliffy画的，不是很标准），其他功能类似

每个功能都包含一个Activity,一个或是多个fragment，以及对应的Presenter在这个MVP模式中，Activity已经不是MVP的一部分了，它更多的作用是全局控制，初始化这个三者之间的关系。如何初始化的呢？是通过

new AddEditTaskPresenter(
        taskId,
   Injection.provideTasksRepository(getApplicationContext()),
        addEditTaskFragment);

这行代码，新建一个TaskPresenter，同时传入一个TaskRepository和Fragment，进行关联的。

所有界面显示的都放在了Fragment里，Frament实现了TaskContract里的View接口，View接口定义了一些显示操作，具体是什么时候显示确实由Presenter来决定，因为Presenter实现所有的业务逻辑。Model层为了可扩展性，也通过接口的形式来实现。

每个功能都包含一个Activity,一个或是多个fragment，以及对应的Presenter在这个MVP模式中，Activity已经不是MVP的一部分了，它更多的作用是全局控制，初始化这个三者之间的关系。如何初始化的呢？是通过

new AddEditTaskPresenter(
taskId,
Injection.provideTasksRepository(getApplicationContext()),
addEditTaskFragment);

这行代码，新建一个TaskPresenter，同时传入一个TaskRepository和Fragment，进行关联的。

所有界面显示的都放在了Fragment里，Frament实现了TaskContract里的View接口，View接口定义了一些显示操作，具体是什么时候显示确实由Presenter来决定，因为Presenter实现所有的业务逻辑。Model层为了可扩展性，也通过接口的形式来实现。

这就是整个MVP的框架，这样的一个好处是：极大的简化了Activity的功能，同时引入了Presenter，把业务逻辑和Model的入口都放在Presenter。有人担心这样会导致Presenter过于庞大，对于这点我说下我的观点：Presenter不是一个类，完全可以根据业务需要引入多个Presenter。