首先声明这一篇完全是根据同事的视频学习的笔记哈~~
MVC
由于其实MVVM、MVP都是基于MVC，所以先看MVC的组成：它主要是抽象出model和view，通过双向绑定，让view可以根据model的状态进行更新
比如发生了一次view的点击，其实这个点击会先给controller，然后controller把动作给model，让model去做事情，然后view会监听model的变化。
MVC的优点：
实现视图层和业务层的分离，一定程度上降低耦合性
降低耦合性能够提高代码可维护性，增强协作的可能性
提高复用性，例如一个model对应多个view
当controller里面的view越来越多，model也会越来越多，如果一个model被多个view监听，这个view可能引发了新的model修改，然后整个数据流就会很混乱：
MVC的缺点：
没有明确模块间的依赖关系和调用方式，导致没有真正的分离
没有明确的状态同步的方式，数据流复杂
所以MVC对于复杂大型项目不容易拓展，于是延伸出了Flux架构。
Flux
它的主要特点就是单向数据流：
Action其实是需要触发状态变更的一个动作，而非仅限于用户操作哦~ 一个完整的数据流是酱紫的：例如一个view点击，会发一个action携带点击相关的参数给dispatcher，dispatcher将动作给store，store去做一些操作影响状态的变更，变更的时候会发一个change事件，让view去更新界面。
下面看一个iOS上面的实现：
#import
#import "FAction.h"
NS_ASSUME_NONNULL_BEGIN
@interface FStore : NSObject
@property (nonatomic, strong, readonly) id state;
-(void)registerForActionClass:(Class)actionClass observer:(id)observer;
-(void)unregisterForActionClass:(Class)actionClass observer:(id)observer;
-(BOOL)responseToAction:(FAction *)action;
-(void)receiveAction:(FAction *)action;
@end
NS_ASSUME_NONNULL_END
store的职责主要是 ① 维护状态state；② 提供注册和注销observer的方法；③ 接收action回调给observer处理
它的实现大概是酱紫的：
#import "FStore.h"
@interface FStore()
@property (nonatomic, strong) NSMapTable *observers;
@property (nonatomic, strong) dispatch_semaphore_t semaphore;
@end
@implementation FStore
- (instancetype)init {
if (self = [super init]) {
_semaphore = dispatch_semaphore_create(1);
_observers = [NSMapTable strongToStrongObjectsMapTable];
}
return self;
}
-(void)registerForActionClass:(Class)actionClass observer:(id)observer {
dispatch_wait(self.semaphore, DISPATCH_TIME_FOREVER);
id actionObservers = [self.observers objectForKey:NSStringFromClass(actionClass)];
NSHashTable *actionObserversTable;
if (actionObservers != nil && [actionObservers isKindOfClass:[NSHashTable class]]) {
actionObserversTable = (NSHashTable *)actionObservers;
} else {
actionObserversTable = [NSHashTable weakObjectsHashTable];
}
[actionObserversTable addObject:observer];
[self.observers setObject:actionObserversTable forKey:NSStringFromClass(actionClass)];
dispatch_semaphore_signal(self.semaphore);
}
-(void)unregisterForActionClass:(Class)actionClass observer:(id)observer {
dispatch_wait(self.semaphore, DISPATCH_TIME_FOREVER);
id actionObservers = [self.observers objectForKey:NSStringFromClass(actionClass)];
if (actionObservers == nil || ![actionObservers isKindOfClass:[NSHashTable class]]) {
dispatch_semaphore_signal(self.semaphore);
return;
}
NSHashTable *actionObserversTable = (NSHashTable *)actionObservers;
if (![actionObserversTable containsObject:observer]) {
dispatch_semaphore_signal(self.semaphore);
return;
}
[actionObserversTable removeObject:observer];
[self.observers setObject:actionObserversTable forKey:NSStringFromClass(actionClass)];
dispatch_semaphore_signal(self.semaphore);
}
-(BOOL)responseToAction:(FAction *)action {
dispatch_wait(self.semaphore, DISPATCH_TIME_FOREVER);
id actionObservers = [self.observers objectForKey:NSStringFromClass([action class])];
if (actionObservers == nil || ![actionObservers isKindOfClass:[NSHashTable class]]) {
dispatch_semaphore_signal(self.semaphore);
return NO;
}
NSHashTable *actionObserversTable = (NSHashTable *)actionObservers;
BOOL shouldResponse = actionObserversTable.count > 0;
dispatch_semaphore_signal(self.semaphore);
return shouldResponse;
}
-(void)receiveAction:(FAction *)action {
if (![self responseToAction:action]) {
return;
}
dispatch_wait(self.semaphore, DISPATCH_TIME_FOREVER);
id actionObservers = [self.observers objectForKey:NSStringFromClass([action class])];
if (actionObservers == nil || ![actionObservers isKindOfClass:[NSHashTable class]]) {
dispatch_semaphore_signal(self.semaphore);
return;
}
NSHashTable *actionObserversTable = (NSHashTable *)actionObservers;
[[actionObserversTable objectEnumerator].allObjects enumerateObjectsUsingBlock:^(id _Nonnull observer, NSUInteger idx, BOOL * _Nonnull stop) {
// 让observer处理action
}];
dispatch_semaphore_signal(self.semaphore);
}
@end
Action就是被传递的动作啦，它主要由两部分组成：类型 & 附带的数据，例如点击action可以附带一下被点击的信息之类的：
#import
NS_ASSUME_NONNULL_BEGIN
@interface FAction : NSObject
@property (nonatomic, readonly, assign) NSInteger actionType;
@property (nonatomic, readonly, strong) id payload;
- (instancetype)initWithActionType:(NSInteger)actionType payload:(id)payload;
@end
NS_ASSUME_NONNULL_END
==========================
#import "FAction.h"
@implementation FAction
- (instancetype)initWithActionType:(NSInteger)actionType payload:(id)payload {
if (self = [super init]) {
_actionType = actionType;
_payload = payload;
}
return self;
}
@end
type一般就是枚举，举个例子~ 例如type是购买，payload是购买数量。
dispatcher主要是动作的分发，将动作转发给对应的store。所以他的职责主要是：① 注册store；② 注销store；③ 将action给store
#import
NS_ASSUME_NONNULL_BEGIN
@class FAction, FStore;
@interface FDispatcher : NSObject
-(void)dispatchAction:(FAction *)action;
-(void)registerStore:(FStore *)store;
-(void)unregisterStore:(FStore *)store;
@end
NS_ASSUME_NONNULL_END
=================================
#import "FDispatcher.h"
#import "FAction.h"
#import "FStore.h"
@interface FDispatcher()
@property (nonatomic, strong) NSMutableSet *stores;
@end
@implementation FDispatcher
- (instancetype)init {
if (self = [super init]) {
_stores = [NSMutableSet set];
}
return self;
}
-(void)dispatchAction:(FAction *)action {
[self.stores enumerateObjectsUsingBlock:^(FStore * _Nonnull store, BOOL * _Nonnull stop) {
[store receiveAction:action];
}];
}
-(void)registerStore:(FStore *)store {
[self.stores addObject:store];
}
-(void)unregisterStore:(FStore *)store {
if ([self.stores containsObject:store]) {
[self.stores removeObject:store];
}
}
@end
Summary - flux
- 实现了View -> Dispatcher -> Store -> View 的单向数据流
- 本身是允许多个store的，但是这样又会有多个数据源的状态同步等问题，所以推荐一个store
- Action是唯一可以造成状态变化的方式，比MVC各种方式都可以触发操作要更明确
- dispatcher全局唯一，对于单store的情况比较多余
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是没有返回的：
redux的重要原则：
- 单一数据源store，避免多状态同步的问题
- state是只读的（这里的理解猜测是：也就是不immutable的，reducer会返回一个新的state对象而非在原有的state上面做修改）
- 引入纯函数的reducer，不会带有副作用
state作为维护状态的对象的基类，没有什么属性，不同state只要继承基类即可，然后添加自己的属性：
#import
NS_ASSUME_NONNULL_BEGIN
@interface RState : NSObject
@end
NS_ASSUME_NONNULL_END
store的主要职责为：① 维护state；② dispatch action；③ 注册/取消注册监听
#import
NS_ASSUME_NONNULL_BEGIN
@class RState, RAction, RReducer, RMiddleware;
@protocol RStoreObserver
-(void)onStateChanged:(RState *)newState;
@end
@interface RStore : NSObject
@property (nonatomic, strong, readonly) RState *state;
-(instancetype)initWithReducer:(RReducer *)reducer;
-(instancetype)initWithReducer:(RReducer *)reducer middleware:(nullable RMiddleware *)middleware;
-(void)registerObserver:(id)observer;
-(void)unregisterObserver:(id)observer;
-(void)dispatchAction:(RAction *)action;
@end
NS_ASSUME_NONNULL_END
它的实现就酱紫：
#import "RStore.h"
#import "RState.h"
#import "RAction.h"
#import "RReducer.h"
#import "RMiddleware.h"
@interface RStore()
@property (nonatomic, strong) RState *state;
@property (nonatomic, strong) RReducer *reducer;
@property (nonatomic, strong) RMiddleware *middleware;
@property (nonatomic, strong) NSHashTable *observers;
@end
@implementation RStore
-(instancetype)initWithReducer:(RReducer *)reducer {
return [self initWithReducer:reducer middleware:nil];
}
-(instancetype)initWithReducer:(RReducer *)reducer middleware:(nullable RMiddleware *)middleware {
if (self = [super init]) {
_reducer = reducer;
_middleware = middleware;
_observers = [NSHashTable weakObjectsHashTable];
}
return self;
}
-(void)registerObserver:(id)observer {
if (observer == nil || [self.observers containsObject:observer]) {
return;
}
[self.observers addObject:observer];
}
-(void)unregisterObserver:(id)observer {
if (observer == nil) {
return;
}
if ([self.observers containsObject:observer]) {
[self.observers removeObject:observer];
}
}
-(void)dispatchAction:(RAction *)action {
if (action.shouldMiddlewareHandle && self.middleware != nil) {
[self.middleware handleAction:action state:self.state];
return;
}
RState *newState = [self.reducer handleAction:action state:self.state];
self.state = newState;
}
- (void)setState:(RState *)state {
_state = state;
[self.observers.objectEnumerator.allObjects enumerateObjectsUsingBlock:^(id _Nonnull observer, NSUInteger idx, BOOL * _Nonnull stop) {
if ([observer respondsToSelector:@selector(onStateChanged:)]) {
[observer onStateChanged:state];
}
}];
}
@end
注意哦，这里是给了store一个reducer和一个middleware，然后reducer里面可以根据处理的action的class来区分如何处理，或者让它内部维护的reducer array来处理；当然你也可以在store里面维护一个dict，记录action对应的reducer，这样就要存很多reducer而已。
action在这里会多一个属性，是不是需要middleware先handle，store会根据这个属性来决定把action给reducer还是middleware，其他两个属性类似flux：
#import
NS_ASSUME_NONNULL_BEGIN
@interface RAction : NSObject
@property (nonatomic, assign) BOOL shouldMiddlewareHandle;
@property (nonatomic, readonly, assign) NSInteger actionType;
@property (nonatomic, readonly, strong) id payload;
@end
NS_ASSUME_NONNULL_END
reducer你可以定义一个协议，也可以定义基类，注意handle是一个纯函数：
#import
NS_ASSUME_NONNULL_BEGIN
@class RAction, RState, RStore;
@interface RReducer : NSObject
@property (nonatomic, weak) RStore *store;
-(RState *)handleAction:(RAction *)action state:(RState *)state;
@end
NS_ASSUME_NONNULL_END
middleware和reducer非常类似，只是handle action的时候没有返回值：
#import
NS_ASSUME_NONNULL_BEGIN
@class RAction, RState, RStore;
@interface RMiddleware : NSObject
@property (nonatomic, weak) RStore *store;
-(void)handleAction:(RAction *)action state:(RState *)state;
@end
NS_ASSUME_NONNULL_END
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的
shouldMiddlewareHandle设为NO以后传递给store，store再去分发这个action给reducer - reducer收到action以后也是通过type找到处理方式，然后修改state里面的属性（
state.detailModel.hasDigg = YES），返回新的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 仍旧是一个很好的模式，因为它很清晰有条理，强迫我们去梳理出一个个独立的状态形成单向数据流，尽量减少不可控的连锁反应。