MVC
1.Model、View、Controller,在Android中Activity以及Fragment相当于这里的Controller,布局文件Layout相当于View,而Model相当于数据库的数据读取,网络数据的获取对应的模型。Controller作为一个媒介,处于View与Model之间,而Model与View有着紧密的联系,耦合性很高。
2.在Android中MVC还是有一定的优点的,上手容易,便于理解,也许没有看到多类似的字眼,但实际项目已经潜移默化的使用了。层次划分稍微明显,虽然Controller有时候充当了View的角色,总体来说还算整洁。也正因为Controller任务太过繁重,并且Model与View耦合度过高。另外既然Activity充当了Controller的角色,当Activity销毁时,稍不注意便会伴随着内存泄漏的风险。
MVP
1.MVP是从MVC演变而来,在安卓中区别于MVC,Activity充当了View的角色,Model数据模型,并且Model与View实现了完全解耦。当然这中架构模式还有另一个变体,Presenter这个角色要么充当一个媒介不做繁重的逻辑控制,要么充当所有的逻辑操作。
View接收用户的操作,并通知到Presenter
Presenter接收到View层的通知,控制Model层进行业务逻辑的处理
Presenter逻辑处理完毕再次封装到Model层
收到Model的完成通知时(回调),更新View层
其中Presenter与View,Presenter与Model是双向通信的,而Model与View实现了完全解耦。
优点:View与Model完全解耦,分层严谨,处理逻辑都交由Presenter(或者Presenter完全不处理逻辑,Model处理逻辑),定位bug方便,便于单元测试。
基础类的实现BaseModel
1 | package com.example.mvp.base; |
BasePresenter
1 | package com.example.mvp.base; |
BaseView
1 | package com.example.mvp.base; |
BaseEntity
1 | package com.example.mvp.bean; |
普通的JavaBean
1 | package com.example.mvp.bean; |
Login模块-LoginModel
1 | package com.example.mvp.login; |
LoginPresenter
1 | package com.example.mvp.login; |
LoginProtocol
1 | package com.example.mvp.login; |
LoginActivity(View)
1 | package com.example.mvp; |
Tips
1.MVP的架构模式还是存在其他变体,当然实际的开发过程中不应该为了架构而架构;要考虑的实际问题很多,应该配合实际的业务需求,考虑到扩展性选择合理的方案。另外合理或许仅仅满足于某一个特定的时期,随着业务的的不断发展,架构模式总是在不断精进的。重要是这种思想领会。
MVVM
1.MVP的升级版,Model—View-ViewModel,同样实现了View与Model之间的解耦,配合Google的data-bindding,由于data-bindding的双向通信,相当于减轻了原MVP中P层任务逻辑,但是MVVM也是有自身的不足,如调用变得复杂,ViewModel同样会变得繁杂。bug传递较深,难以定位。
Android Architecture Components(AAC)
1.Google推荐的架构模型(模型驱动):
2.现在使用的就是这种架构模式,总体还是挺香的。
官方推荐
1.避免将应用的入口指定为数据源。
2.在应用的各个模块之间设定明确定义的职责界限。
3.尽量少公开每个模块中的代码。
4.考虑如何使每个模块可独立测试。
5.专注于应用的独特核心,以使其从其他应用中脱颖而出。
6.保留尽可能多的相关数据和最新数据。
7.将一个数据源指定为单一可信来源。