传统MVP用在项目中是真的方便还是累赘?
2017-02-26 14:51
239 查看
原文地址: https://gold.xitu.io/post/58b25e588d6d810057ed3659
MVP需要创建太多的类和接口,并且每次通信都需要繁琐的通过接口传递信息
这是大多数使用过MVP的朋友,最能感受到的,最近在帮公司技术面,我也时常问应聘者,能否尝试着解决这些问题?
对于逻辑简单的页面可以不使用Presenter,直接在Activity或Fragment中处理逻辑,在Presenter中如果不需要处理数据,也可以不实用Model
Presenter和Model都可以无限制的重用,所以MVP的划分不需要太细粒度,稍微粗粒度一点,即不需要每个Activity或Fragment都给他划分一套MVP,可以几个Activity或Fragment使用同一个Presenter(使用同一个类不是同一个对象,这个Presenter含有可以共用的逻辑),也可一个Activity或Fragment根据不同的需求持有多个不同类型的Presenter对象,Model层同理,这样灵活使用,可以在一定程度上缓解MVP类和接口较多的缺点
比如想重用Presenter,Presenter就必须只含有公用的逻辑,而实际项目中公用的逻辑并不是那么多,所以能减少的类和接口也是很有限的,如果强制将不同页面的逻辑放在同一个Prsenter中,来达到重用的目的,那么每个Activity会被迫实现许多并不需要的方法,得不偿失
因为Presenter基类继承了Activity或Fragment,如果我们需要通过继承使用其他Activity或Fragment,那就又需要修改Presenter基类,一旦某个Activity需要继承其他不同的Activity,那又需要重新创建一个基于此Activity的Presenter基类,导致一个Activity或Fragment有多个不同的Presenter基类
想要在根本上解决以上问题,我想必须换个思路,能不能通过改变传统MVP架构来解决这些问题?
实现*MVP现阶段有两种方式,各有优缺点:*
一个是将Activity或Fragment作为Presenter,抽象一个View层出来
一个是将Activity或Fragment作为View,抽象一个Presenter层出来
我想达到重用Presenter的目的,自然选择了后者
在某一天我突然想到了Handler,他只通过一个handleMessage方法,根据Message的what字段处理不同的操作,这样向上层提供一个统一的入口,下层不管如何改变并不会影响上层,并且同样可以实现多种的操作
于是根据这个思想,我重新改造了MVP架构,让Presenter通过Message和View层通信
具体做法是,VIEW层持有Presenter对象,当用户请求一个事件,则调用Presenter中的方法,并把持有View引用Message传给此方法,此方法处理完请求逻辑后将数据封装到Message中,并通过Message持有的View引用回调View的handleMessage方法,让View做不同的操作,最后释放掉Message的所有引用,放入消息池
Presenter并不直接持有View,方法执行完即表示和View的关系解除
和Handler的原理很像,Handler是将消息放入MessageQueue,Looper去轮循处理消息,我这里是将消息放入,Presenter的方法,并立即处理消息
少写了很多类和接口
并且Presenter只需要通过handleMessage一个方法与View通信,也就不用繁琐的一直添加接口方法,只需要一个Message参数,通过Message封装数据,即使View需要的数据类型发生改变,也不需要更改任何方法,所以也不会影响上层调用
随便重用Presenter,即使你一个Activity,重用10个不同的Presenter,那也只用实现一个handleMessage方法,不需要实现View中其他用不到的方法,通过一个方法同样能做到不同的操作
当Presenter中的方法需要Activity传递一些数据时,也可以将数据封装到Message中传给Presenter,这样即使需要的数据类型发生改变,也不需要更改方法,所以也不会影响上层调用
只有能不断的灵活重用,才能感受到MVP的强大之处
说了这么多还是要看看Demo,具体该怎么做吧?
Go!觉得好一定要右上角Star哦!
– The end
前言(最后奉上福利)
自从问题
但在使用当中我也发现了诸多弊端,导致很多初学者,在写过Sample后,就再也没在自己的项目中使用过MVPMVP需要创建太多的类和接口,并且每次通信都需要繁琐的通过接口传递信息
这是大多数使用过MVP的朋友,最能感受到的,最近在帮公司技术面,我也时常问应聘者,能否尝试着解决这些问题?
解决方案
其实我之前已经有一套解决方案,其实也不能叫解决,只能说是缓解��硬解决
所谓硬解决,便是使用比较暴力的方式��,通过Template自动生成需要的类和接口,这样少去了频繁的复制粘贴软解决
所谓软解决,那就要动动脑子,稍微优雅的解决了��对于逻辑简单的页面可以不使用Presenter,直接在Activity或Fragment中处理逻辑,在Presenter中如果不需要处理数据,也可以不实用Model
Presenter和Model都可以无限制的重用,所以MVP的划分不需要太细粒度,稍微粗粒度一点,即不需要每个Activity或Fragment都给他划分一套MVP,可以几个Activity或Fragment使用同一个Presenter(使用同一个类不是同一个对象,这个Presenter含有可以共用的逻辑),也可一个Activity或Fragment根据不同的需求持有多个不同类型的Presenter对象,Model层同理,这样灵活使用,可以在一定程度上缓解MVP类和接口较多的缺点
并没有完全解决问题
通过上面的解决方案,是可以一定的缓解MVP的缺点,但是并不能完全解决上述缺点比如想重用Presenter,Presenter就必须只含有公用的逻辑,而实际项目中公用的逻辑并不是那么多,所以能减少的类和接口也是很有限的,如果强制将不同页面的逻辑放在同一个Prsenter中,来达到重用的目的,那么每个Activity会被迫实现许多并不需要的方法,得不偿失
寻求解决方法
因此我看了大多数MVP框架,寻求如何彻底改善这个问题,像支付宝团队使用的TheMVP框架,是通过将Activity或Fragment作为Presenter,将UI操作抽到Delegate中,作为View层TheMVP优点
这样做的好处是,不仅可以少写很多类,而且Presenter直接就可以和Activity或Fragment的生命周期做绑定,且可以随便重用View(但大多数场景都是重用Presenter,因为View层变化总是比其它层频繁)TheMVP缺点
缺点就是不能重用Presenter,并且对于Presenter的实现有限制,必须是Activity或Fragment,如果要在其他地方实现Presenter,如Adapter,Dialog就必须根据它的特性重新写对应的Presenter基类因为Presenter基类继承了Activity或Fragment,如果我们需要通过继承使用其他Activity或Fragment,那就又需要修改Presenter基类,一旦某个Activity需要继承其他不同的Activity,那又需要重新创建一个基于此Activity的Presenter基类,导致一个Activity或Fragment有多个不同的Presenter基类
分析问题,解决问题
总结一下MVP的缺点1.粒度不好控制,控制不好就需要写过多的类和接口 2.如要重用presenter可能会实现过多不需要的接口 3.Presenter和View通过接口通信太繁琐,一旦View层需要的数据变化,那么对应的接口就需要更改
想要在根本上解决以上问题,我想必须换个思路,能不能通过改变传统MVP架构来解决这些问题?
实现*MVP现阶段有两种方式,各有优缺点:*
一个是将Activity或Fragment作为Presenter,抽象一个View层出来
一个是将Activity或Fragment作为View,抽象一个Presenter层出来
我想达到重用Presenter的目的,自然选择了后者
在某一天我突然想到了Handler,他只通过一个handleMessage方法,根据Message的what字段处理不同的操作,这样向上层提供一个统一的入口,下层不管如何改变并不会影响上层,并且同样可以实现多种的操作
于是根据这个思想,我重新改造了MVP架构,让Presenter通过Message和View层通信
如何实现
先上张图具体做法是,VIEW层持有Presenter对象,当用户请求一个事件,则调用Presenter中的方法,并把持有View引用Message传给此方法,此方法处理完请求逻辑后将数据封装到Message中,并通过Message持有的View引用回调View的handleMessage方法,让View做不同的操作,最后释放掉Message的所有引用,放入消息池
Presenter并不直接持有View,方法执行完即表示和View的关系解除
和Handler的原理很像,Handler是将消息放入MessageQueue,Looper去轮循处理消息,我这里是将消息放入,Presenter的方法,并立即处理消息
总结
这样就能解决上述的缺点:少写了很多类和接口
并且Presenter只需要通过handleMessage一个方法与View通信,也就不用繁琐的一直添加接口方法,只需要一个Message参数,通过Message封装数据,即使View需要的数据类型发生改变,也不需要更改任何方法,所以也不会影响上层调用
随便重用Presenter,即使你一个Activity,重用10个不同的Presenter,那也只用实现一个handleMessage方法,不需要实现View中其他用不到的方法,通过一个方法同样能做到不同的操作
当Presenter中的方法需要Activity传递一些数据时,也可以将数据封装到Message中传给Presenter,这样即使需要的数据类型发生改变,也不需要更改方法,所以也不会影响上层调用
只有能不断的灵活重用,才能感受到MVP的强大之处
说了这么多还是要看看Demo,具体该怎么做吧?
Go!觉得好一定要右上角Star哦!
Tips
现在的框架是一个比较轻量级的框架,没有网络层,后面会开一个分支提交比较完整的框架和文档,像MVPArms一样– The end
相关文章推荐
- MVP框架模板,方便快速项目开发
- 华夏文明的传统气功到底是有一定科学性还是彻底的伪科学(ZZ)
- 没头没尾--项目开发笔记:先开发UI层还是先开发BusinessRules层!!??
- VS2003和VS2005的Web项目访问局域网中的MS SQL Server2000数据库都报这个错误,安装上SP4以后还是不能解决?(已解决)
- 大家还是要常用用csc,个人感觉有时vs有不少不太方便的东西
- 使用ajax进行项目开发,是福还是祸?
- 大家还是要常用用csc,个人感觉有时vs有不少不太方便的东西。
- MOSS项目开发(5) - 会议还是会议
- asp.net编程模式:WebForm、MVP还是MVC?
- wap项目:统一url 方便计费,采用转向,方便对字符进行编码
- 今天是端午节日,也是我的生日。同时还是我在csdn blog的生日。还是我们一个项目的付款日期哦 。^_^
- 给您参考,现在开发数据库项目用.net 2005成熟吗?还是用.net2003比较有保证
- 利用数据库模版创建方便部署的.Net项目调试环境
- (原)是做两个项目之间的‘驴’,还是做两堆草之间的‘项目经理’
- Jakarta的POI项目操作Excel文件的方便的途径
- 自然系统是分层的,软件项目的设计需要减少层的相干性来推动工作的规划。微软的开发平台还是做得不完善,至少aspx界面需要浪费大量的沟通才能设计好。
- 昨晚开始了为期3个月的初级德语课,课上大家跟老师咿咿呀呀,仿佛回到了蒙学时代,感觉还是不错的!在blog里增加一个GERMAN随笔分类主要是方便自己随时学习,勿怪!Vielen Dank!
- 利用数据库模版创建方便部署的.Net项目调试环境
- IT项目管理,技术重要还是管理重要?
- 新项目到底是使用vs 2005还是vs 2008开发。