android MVP框架

在开发Android应用时,相信很多同学遇到和我一样的情况,虽然项目刚开始构架时自认为MVC层级分的特别明确,但最终往往是一个Activity有好几百行代码,而且逻辑和UI显示完全混杂在一起,导致后续项目的维护成本巨大。一个偶然的机会看到有种MVP模式(Mode-View-Presenter)可以比MVC更好的解耦和,然后好奇的研究了下这个模式并尝试在现在项目中进行推广。下面就把自己目前学习到知识总结出来。

MVP模式将分为两篇博客进行总结:

(一)Android开发MVP模式解析

(二)Android开发MVP模式实践

一、MVP简介

我理解的MVP是由MVC优化衍生出来的一种模式,MVP将MVC中的Controller层进行了优化而生成了Presenter。Presenter单词翻译为“提出者;任命者;主持人”,Presenter层和MVC的Controller一样,负责核心逻辑,但不一样的是Presenter通过接口协议进行数据传递,并阻断了View和Model的直接联系,从而使View和Model更加专注于自身业务逻辑。

二、MVP结构

View

View通常来说就是有Activity、Fragment实现的,View会包含一个或多个Presenter的引用来满足视图的业务逻辑。View和Presenter的交互是双向的,即View层可以调用Presenter的逻辑方法,Presenter也可以控制View的显示。

Presenter

Presenter作为Model和View的桥梁,负责从Model拿到数据进行处理并返回给View。但Presenter和其他两层的沟通是通过接口协议进行的,所以每个Presenter中通常会包涵一个或多个接口协议。

Model

和MVC一样,作为数据仓库只负责对APP数据进行处理。

Android开发MVP模式实践中的示例将APP分为以下四层。

  • Entities:APP中的业务类。
  • Use Cases:负责从将Entities中的数据进行处理和包装。
  • Presenters:从Use Cases获取处理好的数据,然后根据需求逻辑为UI提供合适的数据。
  • UI:从Presenters获取处理好的最终数据,和用户进行直接交互。

这四层设计的原则是代码调用只能从外圆向内圆扩展,内圆不能干预也不需关心外圆的功能逻辑,这符合MVP的思想,Use Cases和Presenters将Entities和UI间隔分离,从而使Entities和UI只需关心自身逻辑,数据处理完全交给其他两层。

这里,有些同学可能会有疑问,说好的Presenters为什么会有Use Cases出来搅局?其实这也是我选择这个工程当做示例的目的,看了好多MVP文章,都在讲Presenter如何通过接口协议和其他两层进行交互,但大都忽略了Presenter层自身的构架,因为仅仅套用MVP模式,虽然在一定程度上降低View的耦合度,但因为Presenter既要处理数据,又要结合需求控制UI交互,所以很可能出现Presenter逻辑的冗余。后文的示例工程在Presenter和Model之间包装了Use Cases,将数据逻辑处理交给UseCases从而让Presenter更专心于UI交互。

三、MVP VS MVC

在把原本MVC模式的代码修改为MVP模式后,总结这两个模式在实际使用过程中的不同点基本上总结为两点:

  • 各个层之间通过接口协议进行沟通;
  • View和Model不再进行直接交互;

详细说明请参考MVC or MVP Pattern - Whats the difference?

四、总结

MVP将会为你的代码带来如下好处:

  • View和Model之间的耦合度降低,使其更关注自身业务逻辑;
  • 便于单元测试;
  • 代码复用率提高;
  • 代码框架更适用于快速迭代开发;

参考资料:

Android上的MVP模式

MVC or MVP Pattern - Whats the difference?

Architecting Android...The Clean way?

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏星流全栈

使用Elixir和CoAP搭建IoT平台 - 01 CoAP介绍

2866
来自专栏SDNLAB

SDNLAB技术分享(十一):VXLAN基础知识

之前Arista在欧洲阶段性的有ATF的类似技术论坛的会议, ARISTA TECHNICAL FORUM, 后来到了美国和APAC, 名字改了, 改为CLOU...

4198
来自专栏闰土大叔

代码里注释写太多,会挨打吗?

前几天,有个同行朋友在我的微信上留言,问我项目代码里注释写太多会挨打吗?顺手还给我甩了一张截图,上面密密麻麻的全是手工注释。

5224
来自专栏程序人生

从 gitlab 事件中吸取的教训

题注:这是一篇去年的文章,今早看到 gitlab 运维人员愚蠢地 rm -rf, 心有戚戚焉,故而重发这篇文章,供大家参考。 ---- 这两天不是很太平,程序圆...

38910
来自专栏石瞳禅的互联网实验室

你们使用的Go IDE要改名了?!

大名鼎鼎的Jetbrains官方博客2017年10月13日的发布文章,邀请各位Gopher和Jetbrains的用户,给大家使用了大半年的IDE改个名字!

921
来自专栏Sorrower的专栏

Mac怎么用, 写在升级Mojave前

4063
来自专栏沃趣科技

Oracle SCN HeadRoom分析与处理

最近几家客户的Oracle数据库开始集中爆发SCN HeadRoom问题,虽然SCN不会真正用完,但是数据库触碰到headroom天花板,还是可能有意想不到的情...

61610
来自专栏北京马哥教育

上班第一天,一个合格的运维应该做什么?

运维行业正在变革,推荐阅读:30万年薪Linux运维工程师成长魔法 作为一名运维工程师,如果你在春节放假期间没有被报警电话和邮件吵醒过,那说明你在放假前的准备...

4108
来自专栏雨过天晴

我是一个线程 0x3704

1892
来自专栏编程一生

架构师之路--从业务角度谈缓存的选型

1935

扫码关注云+社区

领取腾讯云代金券