MVC:
- 视图层(View) 对应于xml布局文件和java代码动态view部分
- 控制层(Controller) MVC中Android的控制层是由Activity来承担的,Activity本来主要是作为初始化页面,展示数据的操作,但是因为XML视图功能太弱,所以Activity既要负责视图的显示又要加入控制逻辑,承担的功能过多。
- 模型层(Model) 针对业务模型,建立数据结构和相关的类,它主要负责网络请求,数据库处理,I/O的操作。
- 总结:
具有一定的分层,
model
彻底解耦,
controller
和
view
并没有解耦
层与层之间的交互尽量使用回调或者去使用消息机制去完成,尽量避免直接持有
controller
和
view
在
android
中无法做到彻底分离,但在代码逻辑层面一定要分清
业务逻辑被放置在
model
层,能够更好的复用和修改增加业务。
MVP:
通过引入接口
BaseView
,让相应的视图组件如
Activity
,
Fragment
去实现
BaseView
,实现了视图层的独立,通过中间层Preseter
实现了
Model
和
View
的完全解耦。
MVP
彻底解决了
MVC
中
View
和
Controller傻傻分不清楚的问题,但是随着业务逻辑的增加,一个页面可能会非常复杂,UI
的改变是非常多,会有非常多的case
,这样就会造成
View
的接口会很庞大。
MVVM:
MVP
中我们说过随着业务逻辑的增加,
UI
的改变多的情况下,会有非常多的跟
UI
相关的
case
,这样就会造成View
的接口会很庞大。而
MVVM
就解决了这个问题,通过双向绑定的机制,实现数据和
UI
内容,只要想改其中一方,另一方都能够及时更新的一种设计理念,这样就省去了很多在View
层中写很多
case
的情况,只需要改变数据就行。
MVVM与DataBinding的关系:
MVVM
是一种思想,
DataBinding
是谷歌推出的方便实现
MVVM
的工具。
看起来
MVVM
很好的解决了
MVC
和
MVP
的不足,但是由于数据和视图的双向绑定,导致出现问题时不太好定位来源,有可能数据问题导致,也有可能业务逻辑中对视图属性的修改导致。如果项目中打算用MVVM的话可以考虑使用官方的架构组件ViewModel
、
LiveData
、
DataBinding
去实现
MVVM
。
实践:
- 如果项目简单,没什么复杂性,未来改动也不大的话,那就不要用设计模式或者架构方法,只需要将每个模块封装好,方便调用即可,不要为了使用设计模式或架构方法而使用。
- 对于偏向展示型的app,绝大多数业务逻辑都在后端,app主要功能就是展示数据,交互等,建议使用mvvm。
- 对于工具类或者需要写很多业务逻辑app,使用mvp或者mvvm都可。