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。