作為一個iOS程序員惦积，MVC一定是我們耳熟能詳?shù)囊环N架構(gòu)模式昔馋，而且當(dāng)你的項目規(guī)模不大的時候筹吐，MVC也確實(shí)有它的優(yōu)勢，它的開發(fā)效率確實(shí)是足夠高秘遏。但當(dāng)你的項目發(fā)展的一定的規(guī)模丘薛，你會發(fā)現(xiàn)傳統(tǒng)的MVC模式會導(dǎo)致C層代碼量劇增，維護(hù)困難等一系列問題邦危，這個時候我們就需要考慮一些其它模式了洋侨。

MV(X)的基本要素

常用的架構(gòu)模式

• MVC
• MVVM
• MVP
• VIPER

前面三種模式都由三個模塊組成：

• Models —— 數(shù)據(jù)層舍扰，負(fù)責(zé)數(shù)據(jù)的處理。
• Views —— 展示層希坚，即所有的UI
• Controller/Presenter/ViewModele（控制器/展示器/視圖模型）——它們負(fù)責(zé)View與Mode之間的調(diào)配

MVC

傳統(tǒng)的MVC

我們所熟知的MVC其實(shí)Apple給我們提供的Cocoa MVC边苹，但其實(shí)MVC最先產(chǎn)生于Web，它原來的樣子應(yīng)該是這樣的

傳統(tǒng)MVC

在這種架構(gòu)下裁僧，View是無狀態(tài)的个束，在Model變化的時候它只是簡單的被Controller重繪，比如網(wǎng)頁中你點(diǎn)擊了一個新的鏈接聊疲，整個頁面就重新加載播急。盡管這種MVC在iOS應(yīng)該里面可以實(shí)現(xiàn)，但是由于MVC的三個模塊都緊密耦合了售睹，每一個模塊都和其它兩種模塊有聯(lián)系桩警，所以即便是實(shí)現(xiàn)了也沒有什么意義。這種耦合還降低了它們的可重用性昌妹，所以捶枢，傳統(tǒng)的MVC在iOS中可以舍棄了。

Apple的MVC

Cocoa MVC

Apple提供的MVC中飞崖，View和Model之間是相互獨(dú)立的烂叔，它們只通過Controller來相互聯(lián)系」掏幔可惜的是Controller得重用性太差蒜鸡，因?yàn)槲覀円话愣及讶唠s的業(yè)務(wù)邏輯放在了Controller中。

現(xiàn)實(shí)中牢裳，我們的MVC一般是這樣的

現(xiàn)實(shí)MVC

為什么會這樣呢逢防？主要還是因?yàn)槲覀兊腢IViewController它本身就擁有一個VIew，這個View是所有視圖的根視圖蒲讯，而且View的生命周期也都由Controoler負(fù)責(zé)管理忘朝，所以View和Controller是很難做到相互獨(dú)立的。雖然你可以把控制器里的一些業(yè)務(wù)邏輯和數(shù)據(jù)轉(zhuǎn)換工作交給Model判帮，但是你卻沒有辦法將一些工作讓View來分?jǐn)偩粥遥驗(yàn)閂iew的主要職責(zé)只是將用戶的操作行為交給Controller去處理而已。于是Controller最終就變成了所有東西的代理和數(shù)據(jù)源晦墙，甚至還有網(wǎng)絡(luò)請求.....還有......所以我們寫的Controller代碼量一般都是非常大的悦昵，隨著當(dāng)業(yè)務(wù)需求的增加，Controller的代碼量會一直增長晌畅，而相對來說View和Model的代碼量就比較穩(wěn)定但指，所以也有人把MVC叫做Massive View Controller，因?yàn)镃ontroller確實(shí)顯得有些臃腫。

在這里關(guān)于Model的劃分枚赡，其實(shí)有一個胖Model和瘦Model之分，它們的差別主要就是把Controller的部分?jǐn)?shù)據(jù)處理職責(zé)交給了胖Model谓谦。

胖Model（Fat Model）：

胖Model包含了部分弱業(yè)務(wù)邏輯贫橙。胖Model要達(dá)到的目的是，Controller從胖Model這里拿到數(shù)據(jù)之后反粥，不用做額外的操作或者只做非常少的操作就能將數(shù)據(jù)應(yīng)用在View上卢肃。
FatModel做了這些弱業(yè)務(wù)之后，Controller可以變得相對skinny一點(diǎn)才顿，它只需要關(guān)注強(qiáng)業(yè)務(wù)代碼莫湘。而強(qiáng)業(yè)務(wù)變動的可能性要比弱業(yè)務(wù)大得多，弱業(yè)務(wù)相對穩(wěn)定郑气，所以弱業(yè)務(wù)塞給Model不會有太大問題幅垮。另一方面，弱業(yè)務(wù)重復(fù)出現(xiàn)的頻率要大于強(qiáng)業(yè)務(wù)尾组，對復(fù)用性要求更高忙芒，如果這部分業(yè)務(wù)寫在Controller，會造成代碼冗余讳侨，類似的代碼會灑得到處都是呵萨，而且一旦弱業(yè)務(wù)有修改，你就會需要修改所有地方跨跨。如果塞到了Model中潮峦，就只需要改Model就夠了。
但是胖Mpdel也不是就是沒有缺點(diǎn)的勇婴，它的缺點(diǎn)就在于胖Model相對比較難移植忱嘹，雖然只是包含弱業(yè)務(wù)，但是它畢竟也是業(yè)務(wù)耕渴，遷移的時候很容易拔出羅布帶出泥德谅，也就是說它耦合了它的業(yè)務(wù)。而且軟件是會成長的萨螺，F(xiàn)atModel也很有可能隨著軟件的成長越來越Fat窄做，最后難以維護(hù)。

瘦Model（Slim Model）：

瘦Model只負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)的表達(dá)慰技，所有業(yè)務(wù)無論強(qiáng)弱一律人給Controller椭盏。瘦Model要達(dá)到的目的是，盡一切可能去編寫細(xì)粒度Model吻商，然后配套各種helper類或者方法來對弱業(yè)務(wù)做抽象掏颊，強(qiáng)業(yè)務(wù)依舊交給Controller。
由于Slim Model跟業(yè)務(wù)完全無關(guān)，它的數(shù)據(jù)可以交給任何一個能處理它數(shù)據(jù)的Helper或其他的對象乌叶，來完成業(yè)務(wù)盆偿。在代碼遷移的時候獨(dú)立性很強(qiáng)，很少會出現(xiàn)拔出蘿卜帶出泥的情況准浴。另外事扭，由于SlimModel只是數(shù)據(jù)表達(dá)，對它進(jìn)行維護(hù)基本上是0成本乐横，軟件膨脹得再厲害求橄，SlimModel也不會大到哪兒去。缺點(diǎn)就在于葡公，Helper這種做法也不見得很好罐农，由于Model的操作會出現(xiàn)在各種地方，SlimModel很容易出現(xiàn)代碼重復(fù)催什，在一定程度上違背了DRY（Don’t Repeat Yourself）的思路涵亏，Controller仍然不可避免在一定程度上出現(xiàn)代碼膨脹。

綜上所述蒲凶，Cocoa MVC在各方面的表現(xiàn)如下：

• 劃分 - View 和 Model 確實(shí)是實(shí)現(xiàn)了分離溯乒，但是 View 和 Controller 耦合的太 厲害
• 可測性 - 因?yàn)閯澐值牟粔蚯宄阅軠y的基本就只有 Model 而已
• 易用 - 相較于其他模式豹爹，它的代碼量最少裆悄。而且基本上每個人都很熟悉它，即便是沒太多經(jīng)驗(yàn)的開發(fā)者也能維護(hù)臂聋。

MVP

MVP

看起來和Cocoa MVC很像光稼，也確實(shí)很像。但是孩等，在MVC中View和COntroller是緊密耦合的艾君，而在MVP中，Presenter完全不關(guān)注ViewController的生命周期肄方，而且View也能被簡單mock出來冰垄，所以在Presenter里面基本沒有什么布局相關(guān)的代碼，它的職責(zé)只是通過數(shù)據(jù)和狀態(tài)更新View权她。
而且在MVP中虹茶，UIVIewController的那些子類其實(shí)是屬于View的。這樣就提供了更好的可測性隅要，只是開發(fā)速度會更高蝴罪，因?yàn)槟惚仨毷謩尤?chuàng)建數(shù)據(jù)和綁定事件。

下面我寫了個簡單的Demo

MVPDemo

由于這里主要是學(xué)習(xí)架構(gòu)模式思想步清，所以我的命名簡單粗暴要门，希望大家理解虏肾。

界面1

界面也很簡單，就是通過點(diǎn)擊按鈕修改兩個label顯示的內(nèi)容

Model很簡單欢搜，就是一個數(shù)據(jù)結(jié)構(gòu)封豪，但在實(shí)際應(yīng)用中，你可以將網(wǎng)絡(luò)請求等一些數(shù)據(jù)處理放在這里

@interface Model : NSObject

@property (nonatomic, strong) NSString *first;
@property (nonatomic, strong) NSString *second;

@end

要讓Presenter和View通信炒瘟，所以我們定義一個協(xié)議吹埠，以實(shí)現(xiàn)Presenter向View發(fā)送命令

@protocol MyProtocol <NSObject>

- (void)setFirst:(NSString *)first;
- (void)setSecond:(NSString *)second;

@end

view/VIewController，實(shí)現(xiàn)該協(xié)議

.h
 @interface ViewController : UIViewController

@property (nonatomic, strong) UILabel *firstLabel;
@property (nonatomic, strong) UILabel *secondLabel;
@property (nonatomic, strong) UIButton *tapButton;

@end


.m主要代碼
- (void)viewDidLoad {
    [super viewDidLoad];
    [self.view addSubview:self.firstLabel];
    [self.view addSubview:self.secondLabel];
    [self.view addSubview:self.tapButton];
    self.presenter = [Presenter new];
    [self.presenter attachView:self];
}

- (void)buttonClicked{
    [self.presenter reloadView];
}

- (void)setFirst:(NSString *)first{
    self.firstLabel.text = first;
}

- (void)setSecond:(NSString *)second{
    self.secondLabel.text = second;
}

Presenter

.h
@interface Presenter : NSObject

- (void)attachView:(id <MyProtocol>)attachView;
- (void)reloadView;

@end


.m
@interface Presenter()

@property (nonatomic, weak) id <MyProtocol> view;
@property (nonatomic, strong) Model *model;

@end

@implementation Presenter

- (instancetype)init
{
    self = [super init];
    if (self) {
        self.model = [Model new];
        self.model.first = @"first";
        self.model.second = @"second";
    }
    return self;
}

- (void)attachView:(id<MyProtocol>)attachView{
    self.view = attachView;
}

- (void)reloadView{
    //可以在這里做一些數(shù)據(jù)處理
    [self.view setFirst:self.model.first];
    [self.view setSecond:self.model.second];
}
@end

這里只是一個簡單的Demo唧领，其實(shí)思想很簡單，就是講業(yè)務(wù)邏輯交給Presenter雌续，而Presenter以命令的形式來控制View斩个。
完整Demo可以看這里

一些說明：

MVP架構(gòu)擁有三個真正獨(dú)立的分層，所以在組裝的時候會有一些問題驯杜，而MVP也成了第一個披露這種問題的架構(gòu)受啥，因?yàn)槲覀儾幌胱孷iew知道Model的信息，所以在當(dāng)前的Controller去組裝是不正確的鸽心，我們應(yīng)該在另外的地方完成組裝滚局。比如我們可以創(chuàng)建一個應(yīng)用層的Router服務(wù)，讓它來負(fù)責(zé)組裝和View-to-View的轉(zhuǎn)場顽频。這個問題下很多模式中都存在藤肢。

下面總結(jié)一下MVP的各方面表現(xiàn)：

• 劃分——我們把大部分職責(zé)都分配到了Presenter和Model里面，而View基本不需要做什么
• 可測性——我們可以通過View來測試大部分業(yè)務(wù)邏輯
• 易用——代碼量差不多是MVC架構(gòu)的兩倍糯景，但是MVP的思路還是蠻清晰的

另外嘁圈，MVP還有一個變體，它的不同主要就是添加了數(shù)據(jù)綁定蟀淮。這個版本的MVP的View和Model直接綁定最住，而Presenter仍然繼續(xù)處理View上的用戶操作，控制View的顯示變化怠惶。這種架構(gòu)和傳統(tǒng)的MVC類似涨缚，所以我們基本可以舍棄。

MVVM

MVVM可以說是MV(X)系列中最新興起的也是最出色的一種架構(gòu)策治，而它也廣受我們iOS程序員喜愛脓魏。

MVVM

MVVM和MVP很像：

• 把ViewController看成View
• View和Model之間沒有緊耦合

另外它還讓VIew和ViewModel做了數(shù)據(jù)綁定。ViewModel可以調(diào)用對Model做更改通惫，也可以再M(fèi)odel更新的時候?qū)ψ陨磉M(jìn)行調(diào)整轧拄，然后通過View和ViewModel之間的綁定，對View進(jìn)行相應(yīng)的更新讽膏。

關(guān)于綁定

在iOS平臺上面有KVO和通知檩电，但是用起來總是覺得不太方便，所以有一些三方庫供我們選擇：

• 基于KVO的綁定庫，如 RZDataBinding 或者 SwiftBond
• 使用全量級的 函數(shù)式響應(yīng)編程 框架,比如ReactiveCocoaRxSwift 或者PromiseKit

實(shí)際上俐末，我們在提到MVVM的時候就很容易想到ReactiveCocoa料按，它也是我們在iOS中使用MVVM的最好工具。但是相對來說它的學(xué)習(xí)成本和維護(hù)成本 也是比較高的卓箫，而且一旦你應(yīng)用不當(dāng)载矿，很可能造成災(zāi)難性的問題。

下面我暫時不用RAC來簡單展示一下MVVM：

MVVM

界面很簡單烹卒，就是點(diǎn)擊一個button修改label里面的數(shù)據(jù)

界面

Model

@interface MVVMModel : NSObject

@property (nonatomic, copy) NSString *text;

@end

@implementation MVVMModel

- (NSString *)text{
    _text = [NSString stringWithFormat:@"newText%d",rand()];
    return _text;
}

ViewModel

@interface MVVMViewModel : NSObject

- (void)changeText;

@end

@interface MVVMViewModel()

@property (nonatomic, strong) NSString *text;
@property (nonatomic, strong) MVVMModel *model;

@end

@implementation MVVMViewModel

- (instancetype)init
{
    self = [super init];
    if (self) {
        self.model = [MVVMModel new];
    }
    return self;
}

- (void)changeText{
    self.text = self.model.text;;
}

Controller

@interface MVVMViewController ()

@property (weak, nonatomic) IBOutlet UILabel *textLabel;
@property (nonatomic, strong) MVVMViewModel *viewModel;

@end

@implementation MVVMViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    self.viewModel = [[MVVMViewModel alloc]init];
    [self.viewModel addObserver:self forKeyPath:@"text" options:NSKeyValueObservingOptionNew context:nil];
}
- (IBAction)buttonClicked:(UIButton *)sender {
    [self.viewModel changeText];
}

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context{
    self.textLabel.text = change[@"new"];
}

MVVM的核心就是View和ViewModel的一個綁定闷盔，這里我只是簡單的通過KVO實(shí)現(xiàn)，看起來并不是那么優(yōu)雅旅急，想要深度使用的話我覺得還是有必要學(xué)習(xí)一下RAC的逢勾，需要完整的Demo請看這里。

下面我們再來對MVVM的各方面表現(xiàn)做一個評價：

• 劃分——MVVM 框架里面的 View 比 MVP 里面負(fù)責(zé)的事情要更多一些藐吮。因?yàn)榍罢呤峭ㄟ^ ViewModel 的數(shù)據(jù)綁定來更新自身狀態(tài)的溺拱，而后者只是把所有的事件統(tǒng)統(tǒng)交給 Presenter 去處理就完了，自己本身并不負(fù)責(zé)更新谣辞。
• 可測性—— 因?yàn)?ViewModel 對 View 是一無所知的迫摔，這樣我們對它的測試就變得很簡單。View 應(yīng)該也是能夠被測試的泥从，但是可能因?yàn)樗鼘?UIKit 的依賴句占，你會直接略過它。
• 易用——它比MVP會更加簡潔躯嫉，因?yàn)樵?MVP 下你必須要把 View 的所有事件都交給 Presenter 去處理辖众，而且需要手動的去更新 View 的狀態(tài)；而在 MVVM 下和敬，你只需要用綁定就可以解決凹炸。

綜上：MVVM 真的很有魅力，因?yàn)樗粌H結(jié)合了上述幾種框架的優(yōu)點(diǎn)昼弟，還不需要你為視圖的更新去寫額外的代碼（因?yàn)樵?View 上已經(jīng)做了數(shù)據(jù)綁定）啤它，另外它在可測性上的表現(xiàn)也依然很棒。

為了簡單易懂舱痘，以上的Demo都非常簡潔变骡，不知道看了這篇博客能否加深你對MV(X)的一些理解，這些理解也僅作為我個人的一些參考芭逝，有什么不對的地方希望大家指出塌碌。