MVC全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写,一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。
1.1数据关系
(1) View 接受用户交互请求
(2) View 将请求转交给Controller
(3) Controller 操作Model进行数据更新
(4) 数据更新之后Model通知View更新数据变化
(5)View 更新变化数据
1.2方式:单向通信
1.3优点
(1) 耦合性降低,MVC本质是分层耦合,减少代码之间的相互影响。
(2) 可扩展性好,由于耦合性低,在增加需求时,改动小,bug出现的机率小。
(3) 有利于代码的维护,MVC三层分工明确,模块职能划分明确。
1.4缺点
随着项目的增大,Activity/Fragment的代码会变得臃肿。
1.5适用场景
适合功能较少,业务逻辑简单,界面不复杂的小型项目
MVP的全称为Model-View-Presenter,分别代表项目中3个不同的模块
模型(Model):负责处理数据的加载或者存储,比如从网络或本地数据库获取数据等;
视图(View):负责界面数据的展示,与用户进行交互;
主持人(Presenter):相当于协调者,是模型与视图之间的桥梁,将模型与视图分离开来。
2.1数据关系
(1) View 接收用户交互请求
(2) View 将请求转交给 Presenter
(3) Presenter 操作Model进行数据更新
(4) Model 通知Presenter数据发生变化
(5) Presenter 更新View数据
2.2方式:双向通信
当业务层处理完成后,需要在view层进行回调。有两种方法:
第一种:fragment、Activity中new出presenter时,一般通过presenter的构造方法把this传进去,当业务层处理完成后就能调到Fragement或者Activity中的方法了。
第二种:通过接口回调的形式实现,fragment或者Activity实现某个View层接口,同样需要在presenter的构造方法传入this。在presenter调用该接口的方法
2.3优点
(1) Model与View完全分离,修改互不影响
因为所有的逻辑交互都发生在一个地方Presenter内部,减少了Model与View层之间的耦合度。
(2) Model层可以封装复用,可以极大的减少代码量。
(3) 一个Preseter可用于多个View,而不需要改变Presenter的逻辑(因为View的变化总是比Model的变化频繁)。
(4) 便于测试。把逻辑放在Presenter中,就可以脱离用户接口来测试逻辑(单元测试)
2.4缺点
随着业务逻辑的增加,一个页面可能会非常复杂,UI 的改变是非常多,造成 View 的接口会很庞大,Presenter层的代码也会越来越臃肿。
2.5适用场景
对于业务很复杂的大型APP来说,过多的Model ,View, Presenter,就会造成视觉疲劳,不利于维护和管理;对于业务很简单的小型APP来说,只需要几个类就可以解决的事情,使用MVP会多出一大堆接口,虽然代码层次清晰了,但开发成本变高了。所以MVP适合不大也不小的项目。
MVVM 是 Model-View-ViewModel 的简写。它是 MVP的改进版,解决MVP的不足。MVVM 就是将其中的 View 的状态和行为抽象化,让我们将视图 UI 和业务逻辑分开。
模型层 (Model):负责从各种数据源中获取数据;
视图层 (View):在 Android 中对应于 Activity 和 Fragment,用于展示给用户和处理用户交互,会驱动 ViewModel 从 Model 中获取数据;
ViewModel 层:用于将 Model 和 View 进行关联,我们可以在 View 中通过 ViewModel 从 Model 中获取数据;当获取到了数据之后,会通过自动绑定,将结果自动刷新到界面上。可以使用官方的架构组件 LiveData、DataBinding 去实现 MVVM架构。 例如DataBindin架构组件会把ViewModel绑定到 XML文件中,保证View中的数值来源都是来自ViewModel,降低布局和逻辑的耦合性。
3.1数据关系
(1) View 接收用户交互请求
(2) View 将请求转交给ViewModel
(3) ViewModel 操作Model数据更新
(4) Model 更新完数据,通知ViewModel数据发生变化
(5) ViewModel 更新View数据
3.2方式:双向绑定。View/Model的变动,只要改其中一方,另一方都能够及时更新到
3.3优点
(1) 低耦合。View可以独立于Model变化和修改,一个ViewModel可以绑定到不同的View上,当View变化的时候Model可以不变,当Model变化的时候View也可以不变。
(2) 可重用性。你可以把一些视图逻辑放在一个ViewModel里面,让很多view重用这段视图逻辑。
(3) 独立开发。开发人员可以专注于业务逻辑和数据的开发(ViewModel),设计人员可以专注于页面设计,生成xml代码。
(4) 可测试。界面向来是比较难测试的,而现在测试可以针对ViewModel来写。
3.4缺点
bug不好找,比如界面异常,有可能是View出错,也有可能是ViewModel的业务逻辑有问题,也有可能是Model的数据出错。对于过大的项目,数据绑定会导致内存开销大,而对于简单的项目,使用MVVM有点大材小用。
3.5适用场景
虽然MVVM兼容当下使用的 MVC/MVP 框架。但是不适用于简单的界面和太过复杂的界面。对于简单界面而言,MVVM反而使逻辑复杂化了,对于复杂界面而言,相对应的ViewModel的构建和维护成本就会变的很高。
这张ViewModel生命周期图是谷歌官方提供的,从这上面显示Activity在横竖屏旋转重建时ViewModel也是一直存在内存中的。
在MVP中View并不直接使用Model,它们之间的通信是通过Presenter 来进行的,所有的交互都发生在Presenter内部,而在MVC中View直接从Model中读取数据而不是通过 Controller。
一句话:没有最好,结合项目本身哪个合适用哪个!
今天的分享结束了,再见~