> MVC/MVP
View强依赖于Model是MVC的主要问题。由此导致很多控件都是根据业务定制,从Android的角度来看,原本可以由一个通用的layout就能实现的控件,由于要绑定实体模型,现在必须要自定义控件,这导致出现大量不必要的重复代码。因此有必要将View和Model进行解耦,而MVP的主要思想就是解耦View和Model。由此引入MVP就显得很自然。
MVP存在的问题:
尽管已经有了大量的应用,但不可否认该模式的还是存在一些问题,这些问题在携程的使用过程中也得到了体现。比如,上下文丢失问题,生命周期问题,内存泄露问题以及大量的自定义接口,回调链变长等问题。可以归纳为:
1.业务复杂时,可能使得Activity变成更加复杂,比如要实现N个IView,然后写更多个模版方法。
2.业务复杂时,各个角色之间通信会变得很冗长和复杂,回调链过长。
3.Presenter处理业务,让业务变得很分散,不能全局掌握业务,很难去回答某个业务究竟是在哪里处理的。
4.用Presenter替代Controller是一个危险的做法,可能出现内存泄漏,生命周期不同步,上下文丢失等问题。
与mvp相关的开源项目:https://github.com/yaozs/YzsBaseActivity https://github.com/yaozs/YzsLib框架模式MVC与MVP在Android中的应用: http://blog.csdn.net/gjnm820/article/details/51733361
Google推出的基于MVP架构的demo,基于此架构我在GitHub上开源了一个项目MinimalistWeatherAndroid MVP框架MVPro的使用和源码分析- http://blog.csdn.net/qibin0506/article/details/49992897
浅谈Andorid开发中的MVP模式- http://blog.csdn.net/loongggdroid/article/details/50592777
1.MVC的基本介绍
MVC全称是Model - View - Controller,是模型(model)-视图(view)-控制器(controller)的缩写。MVC是一种框架模式而非设计模式,GOF把MVC看作是3种设计模式:观察者模式、策略模式与组合模式的合体,而核心是观察者模式。简而言之,框架是大智慧,用来对软件设计进行分工;设计模式是小技巧,对具体问题提出解决方案,以提高代码复用率,降低耦合度。
使用 MVC,把业务逻辑抽离到 Controller 中,让 View 层专注于显示 UI。
1.MVC的优点
(1)首先就是理解比较容易,技术含量不高,这对开发和维护来说成本较低也易于维护与修改。
(2)耦合性不高,表现层与业务层分离各司其职,对开发来说很有利。
2.MVC的缺点
(1)完全理解MVC并不是很容易。使用MVC需要精心的计划,由于它的内部原理比较复杂,所以需要花费一些时间去思考。同时由于模型和视图要严格的分离,这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。
(2)对于小项目,MVC反而会带来更大的工作量以及复杂性。
2.MVC在Android中的应用
Android中对MVC的应用很经典,在Android中视图View层一般采用XML文件进行界面的描述。如下例子:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
而对于模型Model部分则大多对应于本地的数据文件或网络获取的数据体,很多情况下我们对这些数据的处理也会在这一层中进行。
最后的控制器Controller则当之无愧的是右Activity承担。
3.总结
虽说上面的介绍中我们感受到Android在MVC方面的结构,但是,这个框架并非我们自己完成的,而是由framework给我们搭建好的并提供给我们,在平时的开发中,特别是用Android开发,我们并不常用到MVC模式去脱离Android UI系统构建自己的框架结构。
------------------------------------
1.MVP介绍
MVP模式是MVC模式的一个演化版本,MVP全称Model-View-Presenter。目前MVP在Android应用开发中越来越重要了。
在Android中,业务逻辑和数据存取是紧紧耦合的,很多缺乏经验的开发者很可能会将各种各样的业务逻辑塞进某个Activity、Fragment或者自定义View中,这样会使得这些组件的单个类型臃肿不堪。如果不将具体的业务逻辑抽离出来,当UI变化时,你就需要去原来的View中抽离具体业务逻辑,这必然会很麻烦并且易出错。
2.使用MVP的好处
(1)MVP模式会解除View与Model的耦合,有效的降低View的复杂性。同时又带来了良好的可扩展性、可测试性,保证系统的整洁性和灵活性。
(2)MVP模式可以分离显示层与逻辑层,它们之间通过接口进行通信,降低耦合。理想化的MVP模式可以实现同一份逻辑代码搭配不同的显示界面,因为它们之间并不依赖与具体,而是依赖于抽象。这使得Presenter可以运用于任何实现了View逻辑接口的UI,使之具有更广泛的适用性,保证了灵活度。
3.MVP模式的三个角色(1)Presenter – 交互中间人:Presenter主要作为沟通View与Model的桥梁,它从Model层检索数据后,返回给View层,使得View与Model之间没有耦合,也将业务逻辑从View角色上抽离出来。
(2)View – 用户界面:View通常是指Activity、Fragment或者某个View控件,它含有一个Presenter成员变量。通常View需要实现一个逻辑接口,将View上的操作转交给Presenter进行实现,最后,Presenter 调用View逻辑接口将结果返回给View元素。
(3)Model – 数据的存取:Model 角色主要是提供数据的存取功能。Presenter 需要通过Model层存储、获取数据,Model就像一个数据仓库。更直白的说,Model是封装了数据库DAO或者网络获取数据的角色,或者两种数据方式获取的集合。
4.与MVC、MVVM的区别
1.与MVC的区别
从上图可以看出:MVC的耦合性还是较高的,View可以直接访问Model,导致3者之间构成了回路。所以两者的主要区别是,MVP中View不能直接访问Model,需要通过Presenter发出请求,View与Model不能直接通信。
2.与MVVM(Model-View-ViewModel)的区别
MVVM与MVP非常相似,唯一区别是View和Model进行双向绑定,两者之间有一方发生变化则会反应到另一方上。MVVM模式有点像ListView与Adapter、数据集的关系,当数据集发生变化时,调用Adapter的notifyDataSetChanged之后View就直接更新,同时它们之间又没有耦合,使得ListView变得更加灵活。
5.MVP简单实现
可以参考:
1. androidmvp
2. archi
6.MVP 与Activity、Fragment的生命周期由于Presenter 经常性的持有Activity 的强引用,如果在一些请求结束之前Activity 被销毁了,那么Presenter 一直持有Activity 对象,使得Activity 对象无法回收,此时就会发生内存泄露。那么解决方法就是采用弱引用和Activity、Fragment的生命周期来解决这个问题。首先建立一个Presenter 抽象:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
创建一个MVPBaseActivity基类,通过这个基类声明周期函数来控制它与Presenter 的关系。代码如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
MVPBaseActivity含有两个泛型,一个是View的接口类型,一个是Presenter的具体类型。
7.参考
Android官方MVP架构解读:http://blog.csdn.net/ljd2038/article/details/51477475 ; MVP sample: https://github.com/googlesamples/android-architecture