MVP架构在Android平台上的实现分析(一)

MVP也即Model-View-Presenter,是在MVC基础上优化衍生出来的一种软件架构模式,它将MVC中的Controller层进行了优化而生成了Presenter(可理解为主持者或表示者)。

这里Presenter层和MVC的Controller一样,负责核心逻辑,但不同的是,Presenter通过接口协议进行数据传递、功能调用,并阻断了View和Model的直接联系,从而使View和Model更加专注于自身业务逻辑,更好地实现了高内聚、低耦合,同时也方便单元测试。

用下图来说明二者之间的对比,可能更直观些。

在Android平台上,由于Activity/Fragment的生命周期比较复杂以及配置可能发生变化等因素,我们在具体实现时,可以采用多种不同的方案。

本文对Android平台上常见的MVP架构模式,从实现方案的角度尝试做些分析,也欢迎一起深入探讨。

1、Google官方实现

这里使用的例子为TODO-MVP,属于MVP架构的一个基础实现,主要功能是记录、查看待处理任务,管理待办事宜。

其项目工程结构和包,是按照功能来划分的,包括新建/编辑、任务统计、详情查看等模块,如图。

各个子模块的实现比较类似,以新建/编辑任务模块为例,其UML静态结构如下。

其中AddEditTaskActivity完成Presenter的实例化,并将实现了View接口的AddEditTaskFragment对象作为一个参数传递到构造函数中,再通过setPresenter调用,把AddEditTaskPresenter传递给AddEditTaskFragment,建立View和Presenter之间的双向关联。而TasksDataSource接口及TasksRepository类则对应Model,负责完成任务的获取、保存和刷新等处理。

这里获取任务数据的回调处理,是通过Presenter实现TasksDataSource.GetTaskCallback接口来完成的,在onTaskLoaded 和onDataNotAvailable回调中根据数据获取情况更新UI显示。

除了上面提到的基础调用逻辑之外,我们还需要关注该实现中,在Fragment不同的生命周期以及Activity配置发生变化时,对应Presenter的处理方式。

生命周期的处理,又分为两部分。一是在onActivityCreated完成“新建”按钮的属性和点击事件设置,二是在onResume中调用Presenter的start方法,以获取待编辑的任务数据。

配置变化的处理,则是通过AddEditTaskPresenter构造函数中的一个变量来实现的,该变量在任务数据获取完成之后加以复位。Activity中,对应的变量在配置变化时会被保存下来,当再次创建Activity时,该变量被传递给AddEditTaskPresenter,这样避免了由于配置变化带来的数据丢失。

实际上,针对配置变化的问题,Google官方的TODO-MVP-Loders实现给出了另外一种解决方案。该实现利用Loader机制来处理数据访问,对于任务数据的访问管理提供了更强大的功能,包括异步加载数据、监听数据变化以及自动重连等。

与之类似的官方实现还有TODO-MVP-Clean,该实现主要是增加了一个Domain层,可以理解为业务逻辑层,负责处理Presenter发起的业务逻辑相关的操作。个人认为这种实现是对MVP中的Model做了扩展,将业务逻辑与数据访问进一步解耦。

关于Google官方MVP架构实现,暂且分析到这里,欢迎继续关注。

推荐阅读更多精彩内容