浅谈Android MVC、MVP、MVVM架构

为什么做架构设计

谈架构之前,我们应该理解,为什么需要做架构设计?

这个问题,单看网上各种架构优缺点分析、什么解耦、方便测试之类的,是很难有深入的理解的,必须要结合实际的项目经验去思考。相信很多小公司的同学会和我有一样的疑问,没有这些所谓的架构,照样代码能写的很嗨,尤其是在项目迭代初期和写一些简单页面时,直接编程反而更加直观更加快速。架构似乎并没有那么牛逼,能够显著提高我们的开发效率。

其实,架构设计是软件复杂性的产物,它帮助我们把复杂的东西划分成更小的结构,更加便于理解和维护,说白了就是我们接触的项目不够复杂,有架构和无架构之间的差距并不是很大而已。试想一下,在淘宝那样复杂的页面中修改一些代码会是什么情况?无架构的情况下,可能会需要在几千行的Activity代码中去改逻辑,而在MVVM架构中可能只需要在ViewModel和XML文件中修改几个字段而已。

当然,大家可能会反驳,几千行的Activity代码是因为封装没做好等等,确实是这样,自己去做代码拆分、封装也是可以的,这其实就是最初级的架构设计。而架构是什么?架构其实就是这种方法的总结而已,为解决这些复杂性提供了可靠的模板方案。其实架构设计也不是很高深的东西,本质上还是离不开那些软件设计原则,更多的是这些原则的归纳总结,解决具体场景问题的最佳方案而已。学习一个架构,更多是要理解里面的设计思想,能够结合实际项目最好。下面就结合个人的一些项目经验来分享一下个人对Android MVC、MVP、MVVM架构的一些理解吧。

MVC架构

MVC架构也是Android开发最初的模式:XML作为View层、SQLite/文件/网络等作为Model层,Activity作为Controller负责连接View层和Model层。实际开发过程中,Activity作为Controller职责过重,所有的逻辑处理代码、页面展示代码都会集中在这里面,最终导致了几千行代码的Activity类。想想维护这样一个庞大的类会是多么困难,而且这个类不仅涉及页面展示,还涉及逻辑处理&数据获取。我也有过这样的经历,做一个功能,代码看了半天,上线还得小心翼翼生怕影响到其他功能,这也是MVC架构的最大痛点吧。

当然,这种情况下可以进行代码的拆分封装,拆成多个Helper or Util,实现代码的复用,但终归View的逻辑绑定在Activity中,而且Activity承担着Controller的职责,复杂性不可避免,修改的影响面也不好控制。

MVP架构

MVP架构相比于MVC主要有两个进步:
1、单一职责:引入Presenter解放了Activity Controller的职责,把后续代码修改的关注点分离,影响面拆分开来了,也就是说Activity只要保证View对数据的展示正确即可,然后重点关注Presenter中的逻辑代码和数据获取即可
2、解耦:Presenter和View之间通过接口的形式进行依赖,没有强耦合,Presenter也可以不依赖UI进行单元测试(这其实也是国内的一大问题,对测试不够看重,导致这个优点不是很明显了)
MVP核心点是定义出Presenter和View的接口,这个主要是根据用户的交互定义出Presenter的交互接口,并根据页面变化定义出View的接口,然后去实现两者的交互即可,详细见官方demo

说完MVP的优点,也来吐槽一下MVP的缺点吧:MVP最致命的缺点就是Presenter和View的接口定义不具备很强的复用性,导致开发成本的提升。我们项目之前有推过MVP架构,包括BasePresenter和BaseActivity的一些封装都有做,结果还是发现每张页面的开发有点过于繁琐,需要定义出一堆的Presenter和View的接口,这些接口的定义粒度和复用性真的很难把控,尤其是在项目初期,大家甚至懒得定义这些东西了,导致后面不了了之。这其实也警醒了我,架构设计不能是空谈,需要结合实际项目进行落地的,最终目的还是为了提高开发效率。

MVVM

MVVM其实和MVP是类似的结构,只不过把Presenter替换成了ViewModel,但这一点就是非常大的进步!ViewModel和Presenter都是连接View和Model层,但是思想完全不一样,上面有说过Presenter是面向用户交互来定义接口的,而ViewModel是面向数据流的,或者说面向View控件的,这种有什么好处呢?大家想想看,View的控件种类是有限的,它与Model的绑定方式也就是有限的,这样的话就可以把这些绑定关系的处理做成自动化模板的方式了,这就是DataBinding Library做的事情,把View和Model的绑定关系自动化工程化,无需开发者操心,而开发者只需要重点关注数据变化逻辑即可,关注点更少了,是不是开发效率就更高了!

其实,仔细看这些架构、框架的演进过程,终极目标还是为了更高效快捷的开发,而主要手段就是通过标准化模板化的方法,把一些东西做成自动化,节省人力成本,同时也减少了人为误差的风险。这是我觉得学到的最重要的思想吧,也是我们在工作过程中应该思考的,是否有这种工程化自动化的方式去偷懒~

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,117评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,963评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 107,897评论 0 240
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,805评论 0 203
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,208评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,535评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,797评论 2 311
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,493评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,215评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,477评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,988评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,325评论 2 252
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,971评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,055评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,807评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,544评论 2 271
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,455评论 2 266

推荐阅读更多精彩内容