传统MVP用在项目中是真的方便还是累赘?

原文地址: http://www.jianshu.com/p/ac51c9b88af3
qq群:301733278

前言(最后奉上福利)

自从Google在去年放出MVP官方Sample后,越来越多的人开始加入MVP大军,MVP可谓在16年大放异彩,我也乘势推出了我的MVP框架狂刷了一波存在感

问题

但在使用当中我也发现了诸多弊端,导致很多初学者,在写过Sample后,就再也没在自己的项目中使用过MVP

MVP需要创建太多的类和接口,并且每次通信都需要繁琐的通过接口传递信息

这是大多数使用过MVP的朋友,最能感受到的,最近在帮公司技术面,我也时常问应聘者,能否尝试着解决这些问题?

解决方案

其实我之前已经有一套解决方案,其实也不能叫解决,只能说是缓解

硬解决

所谓硬解决,便是使用比较暴力的方式,通过Template自动生成需要的类和接口,这样少去了频繁的复制粘贴

软解决

所谓软解决,那就要动动脑子,稍微优雅的解决了

  1. 对于逻辑简单的页面可以不使用Presenter,直接在ActivityFragment中处理逻辑,在Presenter中如果不需要处理数据,也可以不使用Model

  2. PresenterModel都可以无限制的重用,所以MVP的划分不需要太细粒度,稍微粗粒度一点,即不需要每个ActivityFragment都给他划分一套MVP,可以几个ActivityFragment使用同一个Presenter(使用同一个类不是同一个对象,这个Presenter含有可以共用的逻辑),也可一个ActivityFragment根据不同的需求持有多个不同类型的Presenter对象,Model层同理,这样灵活使用,可以在一定程度上缓解MVP类和接口较多的缺点

并没有完全解决问题

通过上面的解决方案,是可以一定的缓解MVP的缺点,但是并不能完全解决上述缺点

比如想重用Presenter,Presenter就必须只含有公用的逻辑,而实际项目中公用的逻辑并不是那么多,所以能减少的类和接口也是很有限的,如果强制将不同页面的逻辑放在同一个Prsenter中,来达到重用的目的,那么每个Activity会被迫实现许多并不需要的方法,得不偿失

寻求解决方法

因此我看了大多数MVP框架,寻求如何彻底改善这个问题,像支付宝团队使用的TheMVP框架,是通过将ActivityFragment作为Presenter,将UI操作抽到Delegate中,作为View

TheMVP优点

这样做的好处是,不仅可以少写很多类,而且Presenter直接就可以和ActivityFragment的生命周期做绑定 (但使用 Google 最新发布的 Android 架构组件当中的 Lifecycles 就已经可以非常简单的让任何一个类与 ActivityFragment 的生命周期做绑定, 包括 Presenter, 并且 Support Library v26.1.0 已经内嵌这个组件, 不用额外的引入这个组件), 且可以随便重用View(但大多数场景都是重用Presenter,因为View层变化总是比其它层频繁)

TheMVP缺点

缺点就是不能重用Presenter,并且对于Presenter的实现有限制,必须是ActivityFragment,如果要在其他地方实现Presenter,如Adapter,Dialog就必须根据它的特性重新写对应的Presenter基类

因为Presenter基类继承了ActivityFragment,如果我们需要通过继承使用其他ActivityFragment,那就又需要修改Presenter基类,一旦某个Activity需要继承其他不同的Activity,那又需要重新创建一个基于此ActivityPresenter基类,导致一个ActivityFragment有多个不同的Presenter基类

分析问题,解决问题

总结一下MVP的缺点

1.粒度不好控制,控制不好就需要写过多的类和接口
2.如要重用presenter可能会实现过多不需要的接口
3.Presenter和View通过接口通信太繁琐,一旦View层需要的数据变化,那么对应的接口就需要更改

想要在根本上解决以上问题,我想必须换个思路,能不能通过改变传统MVP架构来解决这些问题?

实现MVP现阶段有两种方式,各有优缺点:

一个是将ActivityFragment作为Presenter,抽象一个View层出来

一个是将ActivityFragment作为View,抽象一个Presenter层出来

我想达到重用Presenter的目的,自然选择了后者

在某一天我突然想到了Handler,他只通过一个handleMessage方法,根据Messagewhat字段处理不同的操作,这样向上层提供一个统一的入口,下层不管如何改变并不会影响上层,并且同样可以实现多种的操作

于是根据这个思想,我重新改造了MVP架构,让Presenter通过MessageView层通信

如何实现

先上张图

Architecture.png

具体做法是,VIEW层持有Presenter对象,当用户请求一个事件,则调用Presenter中的方法,并把持有View引用Message传给此方法,此方法处理完请求逻辑后将数据封装到Message中,并通过Message持有的View引用回调ViewhandleMessage方法,让View做不同的操作,最后释放掉Message的所有引用,放入消息池

Presenter并不直接持有View,方法执行完即表示和View的关系解除

Handler的原理很像,Handler是将消息放入MessageQueue,Looper去轮循处理消息,我这里是将消息放入,Presenter的方法,并立即处理消息

总结

这样就能解决上述的缺点:

  1. 少写了很多类和接口

  2. 并且Presenter只需要通过handleMessage一个方法与View通信,也就不用繁琐的一直添加接口方法,只需要一个Message参数,通过Message封装数据,即使View需要的数据类型发生改变,也不需要更改任何方法,所以也不会影响上层调用

  3. 随便重用Presenter,即使你一个Activity,重用10个不同的Presenter,那也只用实现一个handleMessage方法,不需要实现View中其他用不到的方法,通过一个方法同样能做到不同的操作(传统MVP一个页面对应一个Presenter,其实大多数Presenter只有一两个方法,这样导致存在大量代码寥寥无几的Presenter,你有想过将相近的逻辑都写到一个Presenter中,一直重用Presenter有多爽吗)

  4. Presenter中的方法需要Activity传递一些数据时,也可以将数据封装到Message中传给Presenter,这样即使需要的数据类型发生改变,也不需要更改方法,所以也不会影响上层调用

只有能不断的灵活重用,才能感受到MVP的强大之处

当然很多不同的逻辑都写在一个Presenter中,虽然可以少写很多类,但是后面的扩展性肯定不好,所以这个粒度需要自己控制,但是对于外包项目简直是福音

说了这么多还是要看看Demo,具体该怎么做吧?

Go!觉得好一定要右上角Star哦!

公众号

扫码关注我的公众号 JessYan,一起学习进步,如果框架有更新,我也会在公众号上第一时间通知大家

公众号

Hello 我叫 JessYan,如果您喜欢我的文章,可以在以下平台关注我

-- The end

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 143,201评论 1 300
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 61,387评论 1 257
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 94,683评论 0 213
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 41,080评论 0 179
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 48,865评论 1 255
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 38,810评论 1 177
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 30,440评论 2 271
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,200评论 0 167
  • 想象着我的养父在大火中拼命挣扎,窒息,最后皮肤化为焦炭。我心中就已经是抑制不住地欢快,这就叫做以其人之道,还治其人...
    爱写小说的胖达阅读 29,019评论 6 231
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 32,540评论 0 213
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,337评论 2 215
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 30,658评论 1 231
  • 白月光回国,霸总把我这个替身辞退。还一脸阴沉的警告我。[不要出现在思思面前, 不然我有一百种方法让你生不如死。]我...
    爱写小说的胖达阅读 24,255评论 0 32
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,145评论 2 214
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 31,535评论 3 206
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,626评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,028评论 0 166
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 33,555评论 2 230
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 33,652评论 2 231

推荐阅读更多精彩内容