mvc,mvp,mvvm关系和演进

本文介绍了Android开发中常见的三种架构模式:MVC、MVP和MVVM。MVC模式将代码分为Model、View和Controller,但随着代码量增加,Activity仍会变得复杂。MVP模式引入Presenter缓解了Activity的压力,但IView接口可能导致过多方法。MVVM通过数据绑定简化了View和Model的交互,但可能降低代码复用性。每种模式都有其适用场景和改进空间。

一、最开始,我们刚开始学习写代码的过程中,一般都是在一个文件中写(数据,逻辑......),慢慢的,随着代码量的增多,文件可读性越来越差,开始学习将一些的代码抽离出去,将数据信息抽离的情况下,便演变出MVC这种模式。

(1)MVC:

M→Model(数据类,对数据进行一些操作)

V→View(xml布局文件,编写要显示出的内容)

C→Controller(Activity:控制层,完成view和model之间的通信)

优点:将数据Model类进行了抽离,减少了activity中的代码量,增加了一些可读性。

缺点:功能需求是不断在变化的,一些页面代码随之也会不断的增加。activity类中的代码始终还是难逃越来越多的情况,阅读起来还是困难。

二、activity处理的就是view和model之间的通讯,所以要想减轻activity的压力,就需要将view和model绑定操作抽离出去,于是演变出了MVP这种模式。

(2)MVP

M→Model(数据类,对数据进行一些操作)

V→View(Activity:绑定xml文件,所以充当了view层,创建presenter)

P→Presenter(控制层,完成view和model之间的通信,创建model,获取IView)

在这三层中还增加了一个接口层IView(由activity来实现,由presenter来调用),presenter的操作受到了限制,它想操作view层,必须通过IView接口进行操作,IView规定presenter能操作view的哪些功能。

优点:分担出activity逻辑通讯部分,耦合度降低,提高阅读性

缺点:根据业务需求的增加,IView接口方法会不断增加,Activity实现IView接口就必然也要实现它所有方法,比较麻烦

三、为了避免增加业务需求,Activity就要频繁实现接口类的方法,便引入了dataBinding(双向数据绑定),演变出了MVVM这种模式,开启dataBinding,需要在app的build.gradle中进行开启。

(3)MVVM

M→Model(数据类,对数据进行一些操作)

V→View(Activity:绑定xml文件,所以充当了view层,创建ViewModel)

VM→ViewModel(控制层,完成了数据和view绑定,编写逻辑)

优点:双向绑定时,当Model变化时,View-Model会自动更新,View也会自动变化。告别手动一个个findViewById

缺点:数据双向绑定不利于代码重用。XML中包含代码。

四、总结

 

评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

SuperMonsterH

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值