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的层级结构如下:

mvp架构解析

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

mvp架构解析

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

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

mvp架构解析

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

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

mvp架构解析

每个功能都包含一个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。

上一篇:JPA 系列教程16-继承-联合子类-JOINED


下一篇:Google官方MVP模式示例项目解析 todo-mvp