聊聊iOS中的 MVC、MVP、MVVM以及 VIPER等代码组织方式

前言

本文下面所谈的所谓架构二字,核心即是对于客户端的代码组织/职责划分。

现在我们面对架构设计模式的时候有了很多选择:
- MVC
- MVP
- MVVM
- VIPER

首先前三种模式都是把所有的实体归类到了下面三种分类中的一种:

- Models(模型)数据层,或者负责处理数据的 数据接口层。
- Views(视图) - 展示层(GUI)。对于 iOS理论上来来说所有以 UI 开头的类基本都属于这层。
- Controller/Presenter/ViewModel(控制器/展示器/视图模型)
  它是 Model 和 View 之间的胶水或者说是中间人。
  一般来说,当用户对 View 有操作时它负责去修改相应 Model;当 Model 的值发生变化时它负责去更新对应 View。

一、MVC“架构”

(1)MVC - 它原来的样子

经典MVC模式在提出时,大致是上图这样的。更贴近现时代得说,在这种架构下,View 是无状态的,
在Model变化的时候它只是简单的被 Controller重绘,
尽管这种架构可以在应用里面实现,但是由于 MVC 的三种实体被紧密耦合着,每一种实体都和其他两种有着联系,
所以即便是实现了也没有什么意义。

(2)理想化的MVC

View 和 Model 之间是相互独立的,它们只通过 Controller 来相互联系。这样的设计,使得View 和 Model 直接解耦合了。  

但是现实中我们的View依然跟Model耦合,因为如果完全按照这个理想化的MVC的话,View(cell)层的设置都应该在 Controller中,这样的话,Controller会更臃肿。

(3)现实中的MVC

Cocoa MVC 鼓励你去写重控制器是因为 View 的整个生命周期都需要它去管理,
Controller 和 View 很难做到相互独立。虽然你可以把控制器里的一些业务逻辑和数据转换的工作交给 Model,
但是你再想把负担往 View 里面分摊的时候就没办法了;
因为 View 的主要职责就只是讲用户的操作行为交给 Controller 去处理而已。

于是 ViewController 最终就变成了所有东西的代理和数据源,甚至还负责网络请求的发起和取消。最后变得臃肿不堪。

另一方面UIViewController负责了界面跳转的操作,界面跳转的相关配置是直接在对应的UIViewController实例上设置的,这样就很容易把源界面和目的界面耦合起来,表现在导入很多其他头文件。

二、MVP“架构”

MVC的缺点在于并没有区分`业务逻辑和业务展示`, 这对单元测试很不友好. MVP针对以上缺点做了优化, 
它将业务逻辑和业务展示也做了一层隔离, 对应的就变成了MVCP. 
M和V功能不变, 原来的C现在只负责布局, 而所有的业务逻辑全都转移到了P层。
P层处理完了业务逻辑,如果要更改view的显示,那么可以通过回调来实现,这样可以减轻耦合,同时可以单独测试P层的业务逻辑。

在 MVP 中,Presenter 可以理解为松散的控制器,其中包含了视图的 UI 业务逻辑,
所有从视图发出的事件,都会通过代理给 Presenter 进行处理;
同时,Presenter 也通过视图暴露的接口与其进行通信。`而这一般是在 Controller中处理的。`

- View负责界面展示和布局管理,向Presenter暴露视图更新和数据获取的接口 - Presenter负责接收来自View的事件,通过View提供的接口更新视图,并管理Model - Model和MVC中的一样,提供数据模型

 这个流程看起来确实很像 Apple 的 理想化的MVC,它的名字是 MVP(被动变化的 View)。
Apple 的 MVC 实际上是 MVP 吗?不是的,

区别就是IOS中: (1)苹果的理想MVC中UIView相当于View,UIController是Controller,而在MVP中,UIView和UIController都相当于View,所以在 Presenter 里面基本没什么布局相关的代码,它的职责只是通过数据和状态更新 View。 (2)持有关系也不一样,MVC中 C 持有 M和V,但是在MVP中 V 持有 P,P 持有M 。

在 MVP 架构里面,UIViewController 的那些子类其实是属于 View 的,而不是 Presenter。
这种区别提供了极好的可测性,但是这是用开发速度的代价换来的,因为你必须要手动的去创建数据和绑定事件

三、MVVM“架构”

iOS 里面的 ViewModel 到底是个什么东西呢?本质上来讲,他是独立于 UIKit 的, 
View 和 View 的状态的一个呈现(representation)。ViewModel 能主动调用对 Model 做更改,
也能在 Model 更新的时候对自身进行调整,然后通过 View 和 ViewModel 之间的绑定,对 View 也进行对应的更新。
在ios中,MVVM编码可能会成这样
这个图解准确地描述了什么是 MVVM:一个 MVC 的增强版,
我们正式连接了视图和控制器,并将表示逻辑从 Controller 移出放到一个新的对象里,
即 View Model。MVVM 听起来很复杂,但它本质上就是一个精心优化的 MVC 架构。

四、VIPER“架构”

到目前为止,你可能觉得我们把职责划分成三层,这个颗粒度已经很不错了。
现在 VIPER 从另一个角度对职责进行了划分,这次划分了五层。

VIPER并不复杂,它是将原来MVC中的Controller中的各种任务进行了清晰的分解,在写代码时,你会很清楚你正在做什么。
事实上,它比使用了数据绑定技术的MVVM更加简单,就是因为它职责明确。从MVC转到VIPER的过程同样是很清晰的,
它甚至把重构的思路都体现出来了。而MVVM则留下了许多尚未明确的责任,导致不同的人会在某些地方有不同的实现。

*  View
         提供完整的视图,负责视图的组合、布局、更新
         向Presenter提供更新视图的接口
         将View相关的事件发送给Presenter
*   Interactor(交互器) 
          维护主要的业务逻辑功能,向Presenter提供现有的业务用例
          维护、获取、更新Entity
          当有业务相关的事件发生时,处理事件,并通知Presenter
*   Presenter(展示器) 
          接收并处理来自View的事件
          向Interactor请求调用业务逻辑
          向Interactor提供View中的数据
          接收并处理来自Interactor的数据回调事件
          通知View进行更新操作
          通过Router跳转到其他View
*   Entities(实体) 
          纯粹的数据对象。不包括数据访问层,因为这是 Interactor 的职责。
*   Router(路由)
          负责 VIPER 模块之间的转场
          提供View之间的跳转功能,减少了模块间的耦合
          初始化VIPER的各个模块

和MVX的区别

VIPER把MVC中的Controller进一步拆分成了Presenter、Router和Interactor。
和MVP中负责业务逻辑的Presenter不同,VIPER的Presenter的主要工作是在View和Interactor之间传递事件,
并管理一些View的展示逻辑,主要的业务逻辑实现代码都放在了Interactor里。
Interactor的设计里提出了”用例”的概念,也就是把每一个会出现的业务流程封装好,这样可测试性会大大提高。
而Router则进一步解决了不同模块之间的耦合。

优点

VIPER的特色就是`职责明确,粒度细,隔离关系明确`,这样能带来很多优点:
  *   可测试性好。UI测试和业务逻辑测试可以各自单独进行。
  *   易于迭代。各部分遵循单一职责,可以很明确地知道新的代码应该放在哪里。
  *   隔离程度高,耦合程度低。一个模块的代码不容易影响到另一个模块。
  *   易于团队合作。各部分分工明确,团队合作时易于统一代码风格,可以快速接手别人的代码。

缺点

*   一个模块内的类数量增大,代码量增大,在层与层之间需要花更多时间设计接口。
*   模块的初始化较为复杂,打开一个新的界面需要生成View、Presenter、Interactor,并且设置互相之间的依赖关系。

MVC、MVP、MVVM之间的区别

MVC和MVP的关系

我们都知道MVP是从经典的模式MVC演变而来,它们的基本思想有相通的地方:
Controller/Presenter负责逻辑的处理,Model提供数 据,View负责显示。作为一种新的模式,
MVP与MVC有着一个重大的区别:在MVP中View并不直接使用Model,
它们之间的通信是通过 Presenter (MVC中的Controller)来进行的,所有的交互都发生在Presenter内部,
而在现实中的MVC中View会直接从Model中读取数据而不是通过 Controller。

MVVM和MVP的关系

而 MVVM 模式将 Presenter 改名为 ViewModel,基本上与 MVP 模式完全一致。
唯一的区别是,它采用双向绑定(data-binding):View的变动,自动反映在 ViewModel,反之亦然。
这样开发者就不用处理接收事件和View更新的工作,框架已经帮你做好了。

总结

在简单了解了几种架构模式,对于那些让你困惑的问题,我希望你已经找到了答案。但是本文可能也存在错误之处,或者不足之处,希望大家看到有问题的地方在下方留言一起谈论学习,后续可能会持续更新更正本文。

参考文章: 设计框架(MVC、MVP、MVVM、VIPER)的演化说明总结 iOS VIPER架构实践(一):从MVC到MVVM到VIPER 深入分析MVC、MVP、MVVM、VIPER 浅谈开发中的MVVM模式及与MVP和MVC的区别 MVC,MVP,MVVM区别

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏阮一峰的网络日志

MVC,MVP 和 MVVM 的图示

复杂的软件必须有清晰合理的架构,否则无法开发和维护。 MVC(Model-View-Controller)是最常见的软件架构之一,业界有着广泛应用。它本身很容易...

32430
来自专栏杨建荣的学习笔记

使用sysbench压力测试MySQL(三)(r12笔记第6天)

昨天使用gdb调试MySQL中事务临界状态的时候,发现其实有些场景可能比我想得还要复杂一些,所以我在昨天的测试中结尾也是快快扫过,但是表明了意思即可。这一点...

61580
来自专栏杨建荣的学习笔记

Oracle 12c中DBCA搭建备库体验(r11笔记第92天)

Oracle 12c中DBCA有一个特性看起来蛮有意思,就是直接通过DBCA来搭建Data Guard,当然这么说也有点噱头,我们来实际看看。 Ora...

41260
来自专栏Android点滴积累

Android性能优化之启动速度优化

  Android app 启动速度优化,首先谈谈为什么会走到优化这一步,如果一开始创建 app 项目的时候就把这个启动速度考虑进去,那么肯定就不需要重新再来优...

524100
来自专栏Java社区

reg007邀请码分享

我们已经邀请接近1千个名额了,截至2019.09.31,只要留邮箱到公众号:Java社区           我们都会发送邀请码,通过这种方式既可以帮到大家,也...

6.3K40
来自专栏图像识别与深度学习

Android四大组件

19250
来自专栏织云平台团队的专栏

Tcpdump,从入门到不放弃

tcpdump 是一款抓包分析利器,其灵活的过滤规则和对表达式的支持能够让我们在众多的数据报文中抓取到理想的关键信息。本文在介绍 tcpdump 的基本使用方式...

1.3K20
来自专栏Android群英传

基于Google动态化方案的组件化演进

国内Android动态化方案已经蓬勃发展数年之久,在React Natvie、Flutter这些跨平台方案未出现之前,类似Atlas、Replugin、DLA等...

69830
来自专栏腾讯Bugly的专栏

一步一步实现Android的MVP框架

内容大纲: Android 开发框架的选择 如何一步步搭建分层框架 使用 RxJava 来解决主线程发出网络请求的问题 结语 一、Android开发框架的选择 ...

37850
来自专栏做全栈攻城狮

安卓程序员 基础教程 5分钟彻底明白Activity生命周期

本教程致力于讲解及快速进行安卓开发的学习。除安卓开发教程之外,还有Python、C#、网站建设、SEO等教程。对电脑技术感兴趣的朋友直接点击上方“关注”。

15950

扫码关注云+社区

领取腾讯云代金券