iOS架构：MVVM设计模式+RAC响应式编程

我的设计是这样的：

• 一个 View 对应一个 ViewModel，View 界面元素属性与 ViewModel 处理后的数据属性绑定

• Model 只是在有网络数据的时候需要创建，它的作用只是一个数据的中专站，也就是一个极为简介的瘦 Model

• 这里弱化了 Model 的作用，而将对网络数据的处理的逻辑放在 ViewModel 中，也就是说，只有在有网络数据展示的 View 的 ViewModel 中，才会看见 Model 的影子，而处理过后的数据，将变成 ViewModel 的属性，注意一点，这些属性一定要尽量“直观”，比如能写成UIImage 就不要写成 URL

• ViewModel 和 Model 可以视情况看是否需要属性绑定

• Controller 的作用就是将主View通过与之对应的 ViewModel 初始化，然后添加到 self.view，然后就是监听跳转逻辑触发等少部分业务逻辑，当然，ViewController 的路由跳转还可以解放出来。

  注意：这里面提到的绑定，其实就是对属性的监听，当属性变化时，监听者做一些逻辑处理，由此涉及到一个框架————RAC

三：ReactiveCocoa

RAC是一个强大的工具，它和MVVM模式的结合使用只能用一个词形容 ——— 完美。

当然，有些开发者不太愿意用这些东西，大概是因为他们觉得这破坏了代理、通知、监听、闭包等的逻辑观感。但是笔者 MVVM 搭建思路里面会涉及大量的属性绑定、事件传递，运用 RAC 能大量简化代码，使逻辑更加的清晰。

在这之前，如果你没有用过RAC，请先移步：

一般的思路是自定义一个 CollectionviewCell 和一个 ViewModel，因为它们的布局是一样的，我们需要在主 ViewModel 中声明一个数组属性，然后放入两个 ViewModel，分别对应两个 Cell。

image 和 title 这种静态数据我们可以在主ViewModel中为这两个子ViewModel赋值，而下方的具体额度和数量来自网络，网络请求下来的数据通常是:

{    balance:"100"
    redPacket:"3"}

我们需要把”100“转化为”100元“，”3“转化为”3个“。

这个网络数据处理逻辑按正常的逻辑来说是应该放在 ViewModel 中的，但是有个问题，我们这个 collectionviewcell 是复用的，它的 ViewModel 也是同一个，而处理的数据是两个不同的字段，我们如何区分？而且不要忘了，网络请求成功获得的数据是在主 ViewModel 中的，还涉及到传值。再按照这个思路去实现必然更为复杂，所以我干脆一刀切，不管是静态数据还是网络数据的处理，通通放在主 ViewModel 中。

这样做虽然让主 ViewModel 任务繁重，子 ViewModel 过于轻量，但是带来的好处却很多，一一列举：

• 在主 ViewModel 的懒加载中，实现对子 ViewModel 的初始化和赋予初值，在RACCommand 中网络请求成功过后，主 ViewModel 需要再次给子 ViewModel 赋值。赋值条理清晰，两个模块。

• 子 ViewModel 只放其对应的 View 需要的数据属性，作用相当于 Model，但是比 Model 更加灵活，因为如果该 View 内部有着一些点击事件等，我们同样可以在子 ViewModel 中添加RACSubject（或者协议）等，子 ViewModel 的灵活性很高。

• 不管是静态数据还是网络数据统一处理，所有子 ViewModel 的初始化和属性赋值放在一块儿，所有网络请求放在一块儿，所有 RACSubject 放在一块儿，结构更加清晰，维护方便。

3、View

之前讲到，ViewModel 和 Model 交互的唯一场景是有网络请求数据需要展示的情况，而 View 和 ViewModel 却是一一对应，绑不绑定需要视情况而定。下面详细介绍。

自定义View这里分两种情况，分别处理：

（1）非继承有复用机制的 View（不是继承 UICollectionviewCell 等）

这里以界面的主 View 为例

.h

- (instancetype)initWithViewModel:(MineViewModel *)viewModel;

该 View 需要和 ViewModel 绑定，实现相应的逻辑和触发事件，并且保证 ViewModel 的唯一性。

.m

这里就不贴代码了，反正 View 与 ViewModel 的交互无非就是触发网络请求、触发点击事件、将 ViewModel 的数据属性展示在界面上。

（2）继承有复用机制的 View（UICollectionviewCell 等）

最值得注意的地方就是 cell、item 的复用机制问题了。

我们在自定义这些 cell、item 的时候，并不能绑定相应的 ViewModel，因为它的复用原理，将会出现多个 cell（item）的 ViewModel 一模一样，在这里，笔者使用了如下的解决方案：

首先，在自定义的 cell（item）.h 中声明一个 ViewModel 属性。

#import 
<uikit uikit="" h="">
 #import "MineTopCollectionViewCellViewModel.h"@interface MineTopCollectionViewCell : UICollectionViewCell@property (nonatomic, strong) MineTopCollectionViewCellViewModel *viewModel;@end
</uikit>

然后，在该属性的setter方法中给该cell的界面元素赋值：

#pragma mark *** setter ***- (void)setViewModel:(MineTopCollectionViewCellViewModel *)viewModel {    if (!viewModel)  return;
    _viewModel = viewModel;
    
    RAC(self, contentLabel.text) = [[RACObserve(viewModel, content) distinctUntilChanged] takeUntil:self.rac_willDeallocSignal];    self.headerImageView.image = viewModel.headerImage;    self.headerLabel.text = viewModel.headerTitle;
}

ps:这里再次看到RAC（）和RACObserve（）这两个宏，这是属性绑定，如果你不懂，可以先不用管，在后面我会讲解一下我的属性绑定思路，包括不使用 ReactiveCocoa 达到同样的效果。

重写setter的作用大家应该知道吧，就是在 collectionView 的协议方法中写到：

cell.viewModel = self.viewModel.collectionCellViewModel;

的时候，能够执行到该setter方法中，改变该cell的布局。

好吧，这就是精髓，废话不说了。

想了一下，还是贴上主 View 的 .m 代码吧：

@interface MineView () 
<uicollectionviewdelegate nbsp="" uicollectionviewdatasource="" uicollectionviewdelegateflowlayout="">
 @property (nonatomic, strong) UICollectionView *collectionView;@property (nonatomic, strong) MineViewModel *viewModel;@end@implementation MineView- (instancetype)initWithViewModel:(MineViewModel *)viewModel
{    self = [super init];    if (self) {        self.backgroundColor = [UIColor colorWithRed:243/255.0 green:244/255.0 blue:245/255.0 alpha:1];        self.viewModel = viewModel;
        [self addSubview:self.collectionView];
        
        [self setNeedsUpdateConstraints];
        [self updateConstraintsIfNeeded];
        
        [self bindViewModel];
    }    return self;
}
- (void)updateConstraints {
    [self.collectionView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.edges.mas_equalTo(self);
    }];
    [super updateConstraints];
}
- (void)bindViewModel {
    [self.viewModel.autoLoginCommand execute:nil];
}#pragma mark *** UICollectionViewDataSource ***- (NSInteger)numberOfSectionsInCollectionView:(UICollectionView *)collectionView {    return 3;
}
- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section {    if (section == 1) return self.viewModel.dataSorceOfMineTopCollectionViewCell.count;
    ......
}
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath {    if (indexPath.section == 1) {
        MineTopCollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:[NSString stringWithUTF8String:object_getClassName([MineTopCollectionViewCell class])] forIndexPath:indexPath];
            cell.viewModel = self.viewModel.dataSorceOfMineTopCollectionViewCell[indexPath.row];            return cell;
    }
    ......
}
- (UICollectionReusableView *)collectionView:(UICollectionView *)collectionView viewForSupplementaryElementOfKind:(NSString *)kind atIndexPath:(NSIndexPath *)indexPath {
    ......
}#pragma mark *** UICollectionViewDelegate ***- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath {
    [self.viewModel.pushSubject sendNext:nil];
}#pragma mark *** UICollectionViewDelegateFlowLayout ***
    ......#pragma mark *** Getter ***- (UICollectionView *)collectionView {    if (!_collectionView) {
        ......
    }    return _collectionView;
}
- (MineViewModel *)viewModel {    if (!_viewModel) {
        _viewModel = [[MineViewModel alloc] init];
    }    return _viewModel;
}@end
</uicollectionviewdelegate>

4、Controller

这家伙已经解放了。

@interface MineViewController ()@property (nonatomic, strong) MineView *mineView;@property (nonatomic, strong) MineViewModel *mineViewModel;@end@implementation MineViewController#pragma mark *** life cycle ***- (void)viewDidLoad {
    [super viewDidLoad];    self.hidesBottomBarWhenPushed = YES;
    [self.view addSubview:self.mineView];
    [self bindViewModel];
}
- (void)updateViewConstraints {
    [self.mineView mas_makeConstraints:^(MASConstraintMaker *make) {
        make.edges.mas_equalTo(self.view);
    }];
    [super updateViewConstraints];
}
- (void)bindViewModel {
    @weakify(self);
    [[self.mineViewModel.pushSubject takeUntil:self.rac_willDeallocSignal] subscribeNext:^(NSString *x) {
        @strongify(self);
        [self.navigationController pushViewController:[LoginViewController new] animated:YES];
    }];
}#pragma mark *** getter ***- (MineView *)mineView {    if (!_mineView) {
        _mineView = [[MineView alloc] initWithViewModel:self.mineViewModel];
    }    return _mineView;
}
- (MineViewModel *)mineViewModel {    if (!_mineViewModel) {
        _mineViewModel = [[MineViewModel alloc] init];
    }    return _mineViewModel;
}@end

是不是非常清爽，清爽得甚至怀疑它的存在感了（ _{_} ）。

五：附加讲述

1、绑定思想

我想，懂一些 RAC 的人都知道属性绑定吧，RAC（，）和 RACObserve（，），这是最常用的，它的作用是将 A 类的 a 属性绑定到 B 类的 b 属性上，当 A 类的 a 属性发生变化时，B 类的 b 属性会自动做出相应的处理变化。

这样就可以解决相当多的需求了，比如：用户信息展示界面->登录界面->登录成功->回到用户信息展示界面->展示用户信息

以往我们的做法通常是，用户信息展示界面写一个通知监听->登录成功发送通知->用户信息展示界面刷新布局

当然，也可以用协议、闭包什么的。而使用 RAC 的属性绑定、属性联合等一系列方法，将会有事半功倍的效果，充分的降低了代码的耦合度，降低维护成本，思路更清晰。

在上面这个需求中，需要这样做:

将用户信息展示 View 的属性，比如 self.name，self.phone 等与对应的 ViewModel 中的数据绑定。在主 ViewModel 中，为该子 ViewModel 初始化并赋值，用户信息展示 View 的内容就是这个初始值。当主 ViewModel 网络请求成功过后，再一次给该子 ViewModel 赋值，用户信息展示界面就能展示相应的数据了。

而且，我们还可以做得更好，就像我以上的代码里面做的），将 View 的展示内容与 ViewModel 的属性绑定，将 ViewModel 的属性与 Model 的属性绑定，看个图吧：

作者：indulge_in

链接：https://www.jianshu.com/p/4921825f3bbe