首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

【iOS】MVC、Flux、Redux在iOS中的使用

首先声明这一篇完全是根据同事的视频学习的笔记哈~~

MVC

由于其实MVVM、MVP都是基于MVC,所以先看MVC的组成:它主要是抽象出model和view,通过双向绑定,让view可以根据model的状态进行更新

比如发生了一次view的点击,其实这个点击会先给controller,然后controller把动作给model,让model去做事情,然后view会监听model的变化。

MVC

MVC的优点:

实现视图层和业务层的分离,一定程度上降低耦合性

降低耦合性能够提高代码可维护性,增强协作的可能性

提高复用性,例如一个model对应多个view

当controller里面的view越来越多,model也会越来越多,如果一个model被多个view监听,这个view可能引发了新的model修改,然后整个数据流就会很混乱:

MVC的缺点

MVC的缺点:

没有明确模块间的依赖关系和调用方式,导致没有真正的分离

没有明确的状态同步的方式,数据流复杂

所以MVC对于复杂大型项目不容易拓展,于是延伸出了Flux架构。

Flux

它的主要特点就是单向数据流:

flux

Action其实是需要触发状态变更的一个动作,而非仅限于用户操作哦~ 一个完整的数据流是酱紫的:例如一个view点击,会发一个action携带点击相关的参数给dispatcher,dispatcher将动作给store,store去做一些操作影响状态的变更,变更的时候会发一个change事件,让view去更新界面。

下面看一个iOS上面的实现:

store的职责主要是

它的实现大概是酱紫的:

Action就是被传递的动作啦,它主要由两部分组成:类型 & 附带的数据,例如点击action可以附带一下被点击的信息之类的:

type一般就是枚举,举个例子~ 例如type是购买,payload是购买数量。

dispatcher主要是动作的分发,将动作转发给对应的store。所以他的职责主要是:

Summary - flux

实现了View -> Dispatcher -> Store -> View 的单向数据流

本身是允许多个store的,但是这样又会有多个数据源的状态同步等问题,所以推荐一个store

Action是唯一可以造成状态变化的方式,比MVC各种方式都可以触发操作要更明确

dispatcher全局唯一,对于单store的情况比较多余

Redux

Redux

store仍旧维护状态,和flux的区别就是规定整个app只有一个store,action仍旧是动作;不一样的是引入了一个处理同步数据流的reducer,以及处理异步数据流的middleware

例如,操作view的时候也会发出一个action,由于只有一个store,所以可以直接给store,然后store会把动作交给reducer,reducer根据action以及旧的state生成新的state返回给store,store中的state就会更新,也就会通知view去更新显示。

reducer就是一个纯函数,输入就是oldState以及action,然后输出就是一个newState,注意这里就类似函数式编程,reducer是不应该改动到对象的属性的,就是不应该产生副作用,仅仅是用于计算的感觉。也就是无论执行多少次,结果都一样,无论对象是什么,只要输入的一致,输出就不变。

所以reducer不可以修改传入的参数;不能执行有副作用的操作例如调用API请求(每次返回的结果可能不同);也不能调用非纯函数。

middleware是处理异步工作流的,例如点击按钮以后会请求API,区别是middleware是没有返回的:

middleware的点赞流程

redux的重要原则:

单一数据源store,避免多状态同步的问题

state是只读的(这里的理解猜测是:也就是不immutable的,reducer会返回一个新的state对象而非在原有的state上面做修改)

引入纯函数的reducer,不会带有副作用

flux 和 redux 的区别

state作为维护状态的对象的基类,没有什么属性,不同state只要继承基类即可,然后添加自己的属性:

store的主要职责为:

它的实现就酱紫:

注意哦,这里是给了store一个reducer和一个middleware,然后reducer里面可以根据处理的action的class来区分如何处理,或者让它内部维护的reducer array来处理;当然你也可以在store里面维护一个dict,记录action对应的reducer,这样就要存很多reducer而已。

action在这里会多一个属性,是不是需要middleware先handle,store会根据这个属性来决定把action给reducer还是middleware,其他两个属性类似flux:

reducer你可以定义一个协议,也可以定义基类,注意handle是一个纯函数:

middleware和reducer非常类似,只是handle action的时候没有返回值:

middleware在处理action里面可以先做异步动作,然后当异步过程结束以后,再调用store的dispatch action,传入新的action,由于这里可能会用到store,所以其实middleware和reducer是可以持有store哒~ 如果使用注意不要循环引用即可

举个例子,比如点击动态的点赞,按钮会变成选中状态,并且点赞数+1:

创建store,调用点赞的middleware以及reducer的handle action

action需要定义一个type,这里就是点赞type,并携带一个其他数据属性也就是动态的model

store分发action给middleware,middleware会根据action type进行不同处理,这里会先取动态的model去远端请求点赞api

middleware的请求回来以后会把action的设为NO以后传递给store,store再去分发这个action给reducer

reducer收到action以后也是通过type找到处理方式,然后修改state里面的属性(),返回新的state(这里没有创建新的对象,但严格意义应该创建新的)

store会设置新的state,触发observers的state change监听,view在这里把点赞按钮设为选中。

什么时候用redux

需要单一数据源

状态较多

视图层级or数目多

Discussion

Finally,用个人角度以及和同事聊天的感受来探讨一下这几种模式叭,MVX系列(MVC / MVP / MVVM)和Flux其实都只是形式或者说实现上面的不一样,如果MVC会造成绑定混乱,例如按理说,无论是VC绑定还是VM和V绑定,其实都应该是一对一,但是经常我们不能保证这一点,毕竟项目很庞大。

Flux 和 Redux 很重点的一个事儿是:对状态进行梳理。也就是尽量减少那种 VM 一对多的关系所造成的的连锁反应。并且,它更容易测试以及理解的一点在于,监听状态改变后做相应的操作,这一点相比MVX系列更清晰。但是本质上,还是可能会造成连锁反应,只是它更强调有限的状态,让系统更可控的感觉。

所以归根结底,好的设计模式其实不仅仅是说实现上,更重要的是我们如何避免耦合,或者说让耦合能做到泾渭分明。这个是根本,如果可以做到其实用 MVX 和 flux 区别不会特别大,但是 flux 仍旧是一个很好的模式,因为它很清晰有条理,强迫我们去梳理出一个个独立的状态形成单向数据流,尽量减少不可控的连锁反应。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20200902A02CZX00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券