浅谈下mvc和mvp、mvvm到mvvm+Jetpack

作者:抓不住老鼠的猫

三种架构模式

MVC

MVC全名为Model-View-Controller,图解如下

浅谈下mvc和mvp、mvvm到mvvm+Jetpack_第1张图片

  • View:负责与用户交汇,显示界面。
  • Controller:负责接收来自view的请求,处理业务逻辑。
  • Model:负责数据逻辑,网络请求数据以及本地数据库操作数据等。

在MVC架构中,Controller是业务的主要承载者,几乎所有的业务逻辑都在Controller中进行编写。而View主要负责UI逻辑,而Model是数据逻辑,彼此分工。

MVC的本质就是按照UI、业务、数据不同的职责分三大模块,彼此分工。

但是一般的开发中

  • 几乎所有的业务逻辑代码都在controller中进行,会导致非常臃肿,降低项目的可测试性与可维护性。
  • view直接持有controller和model实例,不同职责的代码进行耦合,导致代码耦合性高,模块分工不清晰。

MVC好处:简单。他不需要写很多的代码来让代码解耦,这在在初创公司的小型项目非常有用。小型项目总体的代码量级小,可以提高开发效率

MVP

MVP全名是Model-View-Presenter。图解如下:

浅谈下mvc和mvp、mvvm到mvvm+Jetpack_第2张图片

  • View:UI模块,负责界面显示和与用户交汇。
  • Presenter:负责业务逻辑,起着连接View和Model桥梁的作用。
  • Model:专注于数据逻辑。

MVP和MVC的区别很明显就在这个Presenter中。为了解决MVC中代码的耦合严重性,把业务逻辑都抽离到了Presenter中。这样View和Model完全被隔离,实现了单向依赖,大大减少了耦合度。view和prensenter之间通过接口来通信。

不同的view可以通过实现相同的接口来共享prensenter。presenter也可以通过实现接口来实现动态更换逻辑。Model是完全独立开发的,向外暴露的方法参数中含有callBack参数,可以直接调用callBack进行回调。

  • MVP通过模块职责分工,抽离业务逻辑,降低代码的耦合性
  • 实现模块间的单向依赖,代码思路清晰,提高可维护性
  • 模块间通过接口进行通信,降低了模块间的耦合度,可以实现不同模块独立开发或动态更换

MVP的最大特点就是接口通信,接口的作用是为了实现模块间的独立开发。presenter的作用就是接受view的请求,然后再model中获取数据后调用view的方法进行展示,因为每个界面都是不同的,这就导致了每个Activity/Fragment都必须写一个IView接口,然后还需要再写个IPresenter接口,从而产生了非常多的接口,需要编写大量的代码来进行解耦。 其次,prensenter并没有真正解耦,他还需要调用view的接口进行UI操作,解耦没有彻底。

因此,MVP缺点有:

  • 过度设计导致接口过多造成了接口地狱的问题,编写大量的代码来实现模块解耦,降低了开发效率
  • 并没有彻底进行解耦,prensenter需要同时处理UI逻辑和业务逻辑,presenter臃肿

MVVM
终于到了MVVM,可能很多人都感觉“卧槽这么牛逼的架构我肯定学不会”然后被劝退了继续使用MVC或者MVP。在我看来,MVVM和上面两种架构模式一样都是一种架构思想,只是谷歌推出了jetpack架构组件来让我们更好的使用这种架构模式。

MVVM,全名为Model-View-ViewModel。图解:

浅谈下mvc和mvp、mvvm到mvvm+Jetpack_第3张图片

  • View:和前面的MVP、MVC中的View一样,负责UI界面的显示以及与用户的交汇。
  • Model:同样是负责网络数据获取或者本地数据库数据获取。
  • ViewModel:负责存储view的数据映像以及业务逻辑。

MVVM的view和model和前面的两种架构模式是差不多的,重点在ViewModel。viewModel通过将数据和view进行绑定,修改数据会直接反映到view上,通过数据驱动型思想,彻底把MVP中的Presenter的UI操作逻辑给去掉了。而viewModel是绑定于单独的view的,也就不需要进行编写接口了。但viewModel中依旧有很多的业务逻辑,但是因为把view和数据进行绑定,这样可以让view和业务彻底的解耦了。view可以专注于UI操作,而viewModel可以专注于业务操作。因而:

  • MVVM通过数据驱动型思想,彻底把业务和UI逻辑进行解耦,各模块分工职责明确。

View只需要关注Viewmodel的数据部分,而无需知道数据是怎么来的;而ViewModel只需要关注数据逻辑,而不需要知道UI是如何实现的。View可以随意更换UI实现,但ViewModel却完全不需要改变。

但依旧存在的问题是:viewModel会依旧很臃肿;上手也有一定的难度。

  • MVVM的viewModel依旧很臃肿。
  • MVVM需要学习数据绑定框架,具有一定的上手难度。

为了解决上面两个问题,google推出了上手难度相对较低的mvvm+Jetpack框架

浅谈下mvc和mvp、mvvm到mvvm+Jetpack_第4张图片

做个简单的解析:

  • View对应的就是Activity和Fragment,在这里进行UI操作。
  • ViewModel中包含了LiveData,这是一种可观察数据类型框架。View通过向LIveData注册观察者,当LiveData发生改变时,就会直接调用观察者的逻辑把数据更新到view上。
  • ViewModel完全不需要关心UI操作,只需要专注于数据与业务操作。
  • Repository代表了Model层,Repository对ViewModel进行了减压,把业务操作般到了Repository中,避免了viewModel臃肿。
  • Repository对请求进行判断是要到本地数据库获取还是网络请求获取分别调用不同的模块。

jetpack的架构组件库是一整套完整的架构组件库,包括了:DataBinding,LiveData,ViewModel,Navigation,Lifecycle。下面我们简单了解一下每个组件的功能: 访问基于 activity 构建的可组合 API。

组件名 功能点
DataBinding 1.解基于数据驱动思想,决视图调用一致性问题,实现双向绑定2.避免编写样板式代码,提高效率
LiveData 1.通过唯一可信源获取数据,正确分发数据2.与Lifecycle结合,拥有生命周期感知能力,配合viewModel实现作用域可控3.实现模块的单向依赖,抛弃接口回调
ViewModel 1托管界面状态,解决状态管理问题2.实现跨页面数据分享,并为数据设置作用域,做到作用域可控3.实现单向依赖,避免内存泄露
Lifecycle 1.以简便地方式解决生命周期管理的一致性问题 2.避免内存泄露的情况下让第三方组件随时获取生命周期状态,追踪事故所在的生命周期源,对错过时机的异步操作及时停止
Navigation 1.通过遵循导航定则实现对Fragment的管理

我们只需要遵循他的开发规范,使用他的架构框架,就可以开发出非常健壮的项目。MVVM的本质是什么?

一种基于数据驱动型,将UI逻辑和业务逻辑彻底分离的架构模式。

区别

MVC是不同职责代码分离,MVP是在MVC的基础上通过接口通信降低模块间的耦合性,MVC,MVP都是广义上的架构模式,Android只是他们的一个应用场景。MVVM是专注于页面开发的架构模式,更加契合页面开发模式。

Android 学习笔录

Android 性能优化篇:https://qr18.cn/FVlo89
Android 车载篇:https://qr18.cn/F05ZCM
Android 逆向安全学习笔记:https://qr18.cn/CQ5TcL
Android Framework底层原理篇:https://qr18.cn/AQpN4J
Android 音视频篇:https://qr18.cn/Ei3VPD
Jetpack全家桶篇(内含Compose):https://qr18.cn/A0gajp
Kotlin 篇:https://qr18.cn/CdjtAF
Gradle 篇:https://qr18.cn/DzrmMB
OkHttp 源码解析笔记:https://qr18.cn/Cw0pBD
Flutter 篇:https://qr18.cn/DIvKma
Android 八大知识体:https://qr18.cn/CyxarU
Android 核心笔记:https://qr21.cn/CaZQLo
Android 往年面试题锦:https://qr18.cn/CKV8OZ
2023年最新Android 面试题集:https://qr18.cn/CgxrRy
Android 车载开发岗位面试习题:https://qr18.cn/FTlyCJ
音视频面试题锦:https://qr18.cn/AcV6Ap

你可能感兴趣的:(移动开发,Android,架构,mvc,移动开发,android,架构,安卓,Framework)