安卓应用开发中的MVC、MVP、MVVM、MVI(1)

1. 安卓应用开发中的MVC、MVP、MVVM、MVI

安卓应用开发是一个热门而又复杂的领域,随着技术的不断进步和需求的不断变化,安卓应用开发也需要不断地优化和改进。为了提高安卓应用开发的效率和质量,设计模式是一个重要而又必不可少的工具。设计模式可以帮助我们将程序分解为不同的模块,实现模块内部的高内聚和模块之间的低耦合,从而提高代码的可读性、可维护性、可扩展性和可测试性。

在安卓应用开发中,最常见和最流行的设计模式有四种:MVC(Model-View-Controller)、MVP(Model-View-Presenter)、MVVM(Model-View-ViewModel)和MVI(Model-View-Intent)。这四种设计模式都是基于分层架构思想,将程序分为三层:数据层(Model)、视图层(View)和逻辑层(Controller/Presenter/ViewModel/Intent)。数据层负责管理数据状态和提供数据接口;视图层负责展示用户界面和接收用户输入;逻辑层负责处理业务逻辑和控制数据与视图之间的交互。

虽然这四种设计模式都遵循了分层架构思想,但它们在具体实现上有着不同之处。本文将从以下几个方面对比这四种设计模式:

  • 模块之间的通信方式
  • 模块之间的依赖关系
  • 模块之间的职责划分
  • 优缺点分析
  • 适用场景

1.1 MVC

1.1.1 模块之间的通信方式

在MVC设计模式中,视图层直接与控制器层进行双向通信,控制器层与数据层进行单向通信。如下图所示:

当用户对视图进行操作时,视图会将事件传递给控制器;控制器根据事件类型调用相应的业务逻辑,并更新数据;数据变化后会通知控制器;控制器再根据数据变化更新视图。

1.1.2 模块之间的依赖关系

在MVC设计模式中,视图依赖于控制器,控制器依赖于数据。如下图所示:

由于视图直接与控制器进行双向通信,导致视图与控制器紧密耦合。如果需要修改或替换其中一个组件,则需要同时修改或替换另一个组件。

1.1.3 模块之间的职责划分

在MVC设计模式中,数据层负责管理数据状态和提供数据接口;视图层负责展示用户界面和接收用户输入;控制器层负责处理业务逻辑和控制数据与视图之间的交互。

数据层:通常是一个Java Bean类,封装了应用程序的核心数据,如用户信息、商品信息等。数据层可以从本地或远程获取或存储数据,并提供相应的方法供控制器调用。
视图层:通常是一个XML布局文件,定义了应用程序的用户界面,如按钮、文本框等。视图层可以响应用户的操作,并将事件传递给控制器。
控制器层:通常是一个Activity或Fragment类,实现了应用程序的业务逻辑,如登录、注册、购物等。控制器层可以根据视图传来的事件调用相应的数据方法,并根据数据变化更新视图。
1.1.4 优缺点分析
MVC设计模式是最早也是最简单的一种分层架构思想,它有以下优点:

简单易懂,容易上手
将程序分为三个模块,实现了一定程度上的解耦
有利于代码复用和维护
但MVC设计模式也有以下缺点:

视图与控制器紧密耦合,不利于测试和扩展
控制器过于臃肿,承担了太多职责
数据变化后需要手动更新视图

1.1.5 适用场景

MVC设计模式适合于简单小型的安卓应用开发,当业务逻辑不复杂且视图变化不频繁时,可以使用MVC设计模式快速开发出可运行的应用。

1.2 MVP

1.2.1 模块之间的通信方式

在MVP设计模式中,视图层与逻辑层进行双向通信,逻辑层与数据层进行单向通信。如下图所示:

当用户对视图进行操作时,视图会将事件传递给逻辑层;逻辑层根据事件类型调用相应的业务逻辑,并更新数据;数据变化后会通知逻辑层;逻辑层再根据数据变化更新视图。

1.2.2 模块之间的依赖关系

在MVP设计模式中,视图依赖于接口(View Interface),而不是具体实现(Presenter);同样地,逻辑层也依赖于接口(Model Interface),而不是具体实现(Model)。如下图所示:

由于视图和逻辑层都通过接口进行通信,导致视图和逻辑层松散耦合。如果需要修改或替换其中一个组件,则不需要同时修改或替换另一个组件。

1.2.3 模块之间的职责划分

在MVP设计模式中,数据层负责管理数据状态和提供数据接口;视图层负责展示用户界面和接收用户输入;逻辑层负责处理业务逻辑和控制数据与视图之间的交互。

数据层:与MVC设计模式中的数据层相同,通常是一个Java Bean类,封装了应用程序的核心数据,如用户信息、商品信息等。数据层可以从本地或远程获取或存储数据,并提供相应的方法供逻辑层调用。
视图层:与MVC设计模式中的视图层相似,通常是一个XML布局文件,定义了应用程序的用户界面,如按钮、文本框等。但不同的是,视图层不直接与逻辑层进行通信,而是通过定义一个View Interface接口来规范视图与逻辑之间的交互。View Interface接口定义了一些抽象方法,如showLoading()、showError()、showData()等,由具体的Activity或Fragment类来实现这些方法,并将自身作为参数传给Presenter类。
逻辑层:与MVC设计模式中的控制器层相似,通常是一个Presenter类,实现了应用程序的业务逻辑,如登录、注册、购物等。但不同的是,逻辑层不直接与视图层进行通信,而是通过定义一个Model Interface接口来规范逻辑与数据之间的交互。Model Interface接口定义了一些抽象方法,如login()、register()、buy()等,由具体的Model类来实现这些方法,并将结果回调给Presenter类。Presenter类在构造函数中接收一个View Interface类型的参数,并通过调用该参数的方法来更新视图。

1.2.4 优缺点分析

MVP设计模式是对MVC设计模式的改进,它有以下优点:

视图与逻辑层松散耦合,利于测试和扩展
逻辑层更加清晰,职责更加单一
数据变化后可以自动更新视图
但MVP设计模式也有以下缺点:

需要定义多个接口,增加了代码量和复杂度
视图与逻辑层仍然存在双向通信,不利于数据流的追踪和管理

1.2.5 适用场景

MVP设计模式适合于中等复杂度的安卓应用开发,当业务逻辑较为复杂且视图变化较为频繁时,可以使用MVP设计模式提高代码的可读性、可维护性、可扩展性和可测试性。

1.3 MVVM

1.3.1 模块之间的通信方式

在MVVM设计模式中,视图层与逻辑层进行单向通信,逻辑层与数据层进行双向通信。如下图所示:

当用户对视图进行操作时,视图会将事件传递给逻辑层;逻辑层根据事件类型调用相应的业务逻辑,并更新数据;数据变化后会自动同步到逻辑层;逻辑层再根据数据变化自动更新视图。

1.3.2 模块之间的依赖关系

在MVVM设计模式中,视图依赖于逻辑层(ViewModel),而不是接口(View Interface);逻辑层依赖于数据层(Model),而不是接口(Model Interface)。如下图所示:

由于视图和逻辑层之间通过数据绑定进行通信,导致视图和逻辑层完全解耦。如果需要修改或替换其中一个组件,则不需要同时修改或替换另一个组件。

1.3.3 模块之间的职责划分

在MVVM设计模式中,数据层负责管理数据状态和提供数据接口;视图层负责展示用户界面和接收用户输入;逻辑层负责处理业务逻辑和控制数据与视图之间的交互。

数据层:与MVC和MVP设计模式中的数据层相同,通常是一个Java Bean类,封装了应用程序的核心数据,如用户信息、商品信息等。数据层可以从本地或远程获取或存储数据,并提供相应的方法供逻辑层调用。
视图层:与MVC和MVP设计模式中的视图层相似,通常是一个XML布局文件,定义了应用程序的用户界面,如按钮、文本框等。但不同的是,视图层不直接与逻辑层进行通信,而是通过使用Data Binding库来实现视图与逻辑之间的自动同步。Data Binding库可以将XML布局文件中的UI组件与ViewModel类中的属性或方法进行绑定,并在两者之间建立一个观察者模式。当UI组件发生变化时,会自动触发ViewModel类中对应的方法;当ViewModel类中对应的属性发生变化时,会自动更新UI组件。
逻辑层:与MVC和MVP设计模式中的控制器层和Presenter层相似,通常是一个ViewModel类,实现了应用程序的业务逻辑,如登录、注册、购物等。但不同的是,逻辑层不直接与视图层进行通信,而是通过使用LiveData库来实现逻辑与数据之间的自动同步。LiveData库可以将ViewModel类中的属性或方法与Model类中的属性或方法进行绑定,并在两者之间建立一个观察者模式。当Model类中对应的属性发生变化时,会自动更新ViewModel类中对应的属性;当ViewModel类中对应的方法被调用时,会自动调用Model类中对应的方法。

1.3.4 优缺点分析

MVVM设计模式是对MVP设计模式的改进,它有以下优点:

视图与逻辑层完全解耦,利于测试和扩展
逻辑层更加清晰,职责更加单一
数据变化后可以自动更新视图和逻辑
代码量更少,复杂度更低
但MVVM设计模式也有以下缺点:

需要使用第三方库来实现数据绑定和数据同步
数据流不易追踪和管理

1.3.5 适用场景

MVVM设计模式适合于复杂大型的安卓应用开发,当业务逻辑非常复杂且视图变化非常频繁时,可以使用MVVM设计模式提高代码的可读性、可维护性、可扩展性和可测试性。

1.4 MIVI

请参考我的另一篇文章,我想把MVI讲的详细一些。
安卓应用开发中的MVC、MVP、MVVM、MVI(2) - 简书 (jianshu.com)

1.5 总结

本文介绍了三种常见的安卓开发设计模式:MVC、MVP和MVVM,并分别从模块之间的通信方式、依赖关系、职责划分、优缺点分析和适用场景等方面进行了比较。希望本文能够帮助读者理解并选择合适的设计模式来提高安卓开发效率和质量。👏👏👏

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

推荐阅读更多精彩内容