MVC
1、角色
- View
- android.view.View及其子类+布局文件作为view层,负责视图的创建渲染;
- Controller
- 通常是Activity/Fragment作为Controller角色,负责视图逻辑、业务流程处理;
- Model
3、说明
- 作为入门级、安卓早期APP架构、Activity的功能强大,也使得Controller层与View并没有明显的界限,Activity/Fragment常常作为控制器+部分View实现存在,所以也导致Activity/Fragment的代码过分臃肿、难以维护;
- 在MVC架构中,model、view之间没有隔离,view可以直接使用model,model也可以直接将回调传递给view,所以作为视图逻辑、业务处理的Controller层被弱化了,没有起到解耦的作用;
MVP
1、角色
- View
- View+Activity/Fragment,负责视图创建渲染、展示逻辑,视图控制器;
- Activity/Fragment中持有一个Presenter的实例,进行业务接口调用;
- 实现iView接口、定义具体的数据传递逻辑,方式没有多种,比如:1)Activity/Fragment实现接口;2)创建具体iView类并实现iView接口、持有Activity/Fragment的弱引用···等等;
- Presenter
- iPresenter:定义数据处理、业务逻辑的接口,由其子类负责实现具体的功能,不会直接拥有View的实例,但通过iView接口将具体的视图数据传递到view层;
- iView:定义视图层的数据展示接口,解耦view、presenter;
- Model
- 定义的数据IO层,没有统一的定义、不要求一定有封装;
- 但基于代码复用,可创建统一的基类,封装SQLite、http操作请求的实例对象创建,控制生命周期;
2、结构定义
3、说明
- 使用iView+iPresenter结构,优化了原有的MVC架构,拆分了Acitvity的数据业务处理功能,使Activity作为试图空时期的一部分,而Preserter作为一个真正独立的数据业务处理角色;
- 但这样的实现方式使代码冗余程度大大增加,往往一个功能的实现,iPreserter、iView都需要定义新的接口,复用过程也留下会有许多不需要实现的函数;
MVVM
1、角色
- View
- 与MVC一样,View+Activity/Fragment,负责视图创建渲染、展示逻辑,视图控制器;
- ViewModel
- VM:ViewModel本身与MVC的Presenter是一样的角色,负责处理数据业务逻辑,但vm中不应持有view层的实例引用,接口中也不应该传递view对象作为参数,也不应该具体化定义该ViewModel是为哪个具体的View层提供服务;
- DataBinding:
- Model
- 与MVC结构中Model定义一致;
2、结构定义
3、说明
- 由Google定义及提供,作为Jetpack的一部分,提供了组件层上的支持;
- 观察者模式,应用事件订阅、数据持有权转移,使View、ViewModel彻底解绑,也无需定义view、vm之间数据传递的接口;
- ViewModel中可以接收来自View的事件、也可以发布时间或改变数据以通知数据订阅者(也就是View层)进行刷新;
- 对于布局xml文件有一定的代码入侵,虽然布局文件定义之后代码里也可以不使用;
- 但同时,view与vm之间没有直接的数据通讯方式,所以在简单应用或界面上的使用,可能会使原本简单的事情变得复杂,酌情考虑使用(MVP同样);