赞
踩
目录
1、耦合性低
2、可扩展性好
3、模块职责划分明确
1、conroller层过于冗余,使其可阅读性大大降低
2、其中M层和V没有很好地进行隔离;他们之间可以进行直接的交互
1、M:model层,即数据模型;V:即view层,只是xml文件;C:conroller(控制器),是一个桥梁的作用, 这里用activity作为conroller层
2、利用mvc设计模式,可以让项目有比较好的可扩展和维护性
3、可以在小型项目中使用
1、模型与视图完全分离,我们可以修改视图儿不影响视图。即:M层和V层无法直接交互
2、可以更高效的使用模型,因为所有的交互都被放在了P(persenter)层中,这也就导致我们可以多个视图,使用同一个P(persenter),而不需要改变P(persenter)的逻辑。即:视图的变化频率永远高于模型
3、逻辑放在P(persenter)中,则可以让这些逻辑单独运行。即:可以做单元测试
1、接口类的爆炸,使用mvp时,将会导致类文件以及接口文件过多,进而导致APP体积的增大
2、视图和P的交互将会过于频繁,这样就导致他们的联系过于紧密。即:视图有了变化,则P则需要做相应的修改
1、M:依然是业务逻辑和实体模型;V:对应activity以及xml文件,其中activity负责view的绘制以及与用户的交互;P:负责M与V的交互,并且气到完全隔离的作用;
2、使用时会有内存泄漏现象:即在V层被销毁时,M层还在做耗时操作,这是P层同时持有M以及V层,当V层销毁时,M层无法被销毁,就会导致V层无法被内存回收掉。这个时候就会造成内存泄漏的问题,解决方式就是在V层销毁时强制回收掉P层;或者使用弱引用的方式(在使用弱引用前,需要判空,保证引用类不为null)
3、需要在中大型项目中使用,小型项目不可取
1、低耦合:V层可以独立于M层进行变化和修改,而且VM也可以绑定到不同的V上
2、可重用性:可以将一些视图逻辑放到一个VM层中,方便多个V层进行调用
3、独立开发:可以将V层和VM层单独分开来进行研发
4、可测试:可以单独对VM层进行测试
1、对问题排查的难度增加
2、类会增多,每个V都会附带一个VM
3、调用的复杂度增加,毕竟很多调用会比较隐性,刚开始很难知道真实的数据模式是谁
1、M:实体模型和业务逻辑;V:对应activity以及xml文件,其中activity负责view的绘制以及与用户的交互;VM:负责监听m中数据的改变并控制数据的更新;
2、M与V是无法直接联系的,都是通过VM进行交互的,M与VM数据是双向绑定的,因此当M中的数据做出改变时,会出发V层的刷新,V中由于用户操作二造成的改变也会同步到M中
3、目前大小都可以使用
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。