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

MV(X)的基本要素

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

MVC
MVVM
MVP
VIPER

前面三種模式都由三個(gè)模塊組成：

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，它原來(lái)的樣子應(yīng)該是這樣的

傳統(tǒng)MVC

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

Apple的MVC

Cocoa MVC

Apple提供的MVC中，View和Model之間是相互獨(dú)立的，它們只通過(guò)Controller來(lái)相互聯(lián)系?？上У氖荂ontroller得重用性太差，因?yàn)槲覀円话愣及讶唠s的業(yè)務(wù)邏輯放在了Controller中。

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

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

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

在這里關(guān)于Model的劃分，其實(shí)有一個(gè)胖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可以變得相對(duì)skinny一點(diǎn)，它只需要關(guān)注強(qiáng)業(yè)務(wù)代碼。而強(qiáng)業(yè)務(wù)變動(dòng)的可能性要比弱業(yè)務(wù)大得多，弱業(yè)務(wù)相對(duì)穩(wěn)定，所以弱業(yè)務(wù)塞給Model不會(huì)有太大問(wèn)題。另一方面，弱業(yè)務(wù)重復(fù)出現(xiàn)的頻率要大于強(qiáng)業(yè)務(wù)，對(duì)復(fù)用性要求更高，如果這部分業(yè)務(wù)寫在Controller，會(huì)造成代碼冗余，類似的代碼會(huì)灑得到處都是，而且一旦弱業(yè)務(wù)有修改，你就會(huì)需要修改所有地方。如果塞到了Model中，就只需要改Model就夠了。
但是胖Mpdel也不是就是沒(méi)有缺點(diǎn)的，它的缺點(diǎn)就在于胖Model相對(duì)比較難移植，雖然只是包含弱業(yè)務(wù)，但是它畢竟也是業(yè)務(wù)，遷移的時(shí)候很容易拔出羅布帶出泥，也就是說(shuō)它耦合了它的業(yè)務(wù)。而且軟件是會(huì)成長(zhǎng)的，F(xiàn)atModel也很有可能隨著軟件的成長(zhǎng)越來(lái)越Fat，最后難以維護(hù)。

瘦Model（Slim Model）：

瘦Model只負(fù)責(zé)業(yè)務(wù)數(shù)據(jù)的表達(dá)，所有業(yè)務(wù)無(wú)論強(qiáng)弱一律人給Controller。瘦Model要達(dá)到的目的是，盡一切可能去編寫細(xì)粒度Model，然后配套各種helper類或者方法來(lái)對(duì)弱業(yè)務(wù)做抽象，強(qiáng)業(yè)務(wù)依舊交給Controller。
由于Slim Model跟業(yè)務(wù)完全無(wú)關(guān)，它的數(shù)據(jù)可以交給任何一個(gè)能處理它數(shù)據(jù)的Helper或其他的對(duì)象，來(lái)完成業(yè)務(wù)。在代碼遷移的時(shí)候獨(dú)立性很強(qiáng)，很少會(huì)出現(xiàn)拔出蘿卜帶出泥的情況。另外，由于SlimModel只是數(shù)據(jù)表達(dá)，對(duì)它進(jìn)行維護(hù)基本上是0成本，軟件膨脹得再厲害，SlimModel也不會(huì)大到哪兒去。缺點(diǎn)就在于，Helper這種做法也不見得很好，由于Model的操作會(huì)出現(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 耦合的太厲害
可測(cè)性 - 因?yàn)閯澐值牟粔蚯宄?，所以能測(cè)的基本就只有 Model 而已
易用 - 相較于其他模式，它的代碼量最少。而且基本上每個(gè)人都很熟悉它，即便是沒(méi)太多經(jīng)驗(yàn)的開發(fā)者也能維護(hù)。

MVP

看起來(lái)和Cocoa MVC很像，也確實(shí)很像。但是，在MVC中View和COntroller是緊密耦合的，而在MVP中，Presenter完全不關(guān)注ViewController的生命周期，而且View也能被簡(jiǎn)單mock出來(lái)，所以在Presenter里面基本沒(méi)有什么布局相關(guān)的代碼，它的職責(zé)只是通過(guò)數(shù)據(jù)和狀態(tài)更新View。
而且在MVP中，UIVIewController的那些子類其實(shí)是屬于View的。這樣就提供了更好的可測(cè)性，只是開發(fā)速度會(huì)更高，因?yàn)槟惚仨毷謩?dòng)去創(chuàng)建數(shù)據(jù)和綁定事件。

下面我寫了個(gè)簡(jiǎn)單的Demo

MVPDemo

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

界面1

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

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

@interface Model : NSObject

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

@end

要讓Presenter和View通信，所以我們定義一個(gè)協(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

這里只是一個(gè)簡(jiǎn)單的Demo，其實(shí)思想很簡(jiǎn)單，就是講業(yè)務(wù)邏輯交給Presenter，而Presenter以命令的形式來(lái)控制View。
完整Demo可以看這里

一些說(shuō)明：

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

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

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

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

MVVM

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

MVVM

MVVM和MVP很像：

把ViewController看成View
View和Model之間沒(méi)有緊耦合

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

關(guān)于綁定

在iOS平臺(tái)上面有KVO和通知，但是用起來(lái)總是覺得不太方便，所以有一些三方庫(kù)供我們選擇：

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

實(shí)際上，我們?cè)谔岬組VVM的時(shí)候就很容易想到ReactiveCocoa，它也是我們?cè)趇OS中使用MVVM的最好工具。但是相對(duì)來(lái)說(shuō)它的學(xué)習(xí)成本和維護(hù)成本也是比較高的，而且一旦你應(yīng)用不當(dāng)，很可能造成災(zāi)難性的問(wèn)題。

下面我暫時(shí)不用RAC來(lái)簡(jiǎn)單展示一下MVVM：

MVVM

界面很簡(jiǎn)單，就是點(diǎn)擊一個(gè)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的一個(gè)綁定，這里我只是簡(jiǎn)單的通過(guò)KVO實(shí)現(xiàn)，看起來(lái)并不是那么優(yōu)雅，想要深度使用的話我覺得還是有必要學(xué)習(xí)一下RAC的，需要完整的Demo請(qǐng)看這里。

下面我們?cè)賮?lái)對(duì)MVVM的各方面表現(xiàn)做一個(gè)評(píng)價(jià)：

劃分——MVVM 框架里面的 View 比 MVP 里面負(fù)責(zé)的事情要更多一些。因?yàn)榍罢呤峭ㄟ^(guò) ViewModel 的數(shù)據(jù)綁定來(lái)更新自身狀態(tài)的，而后者只是把所有的事件統(tǒng)統(tǒng)交給 Presenter 去處理就完了，自己本身并不負(fù)責(zé)更新。
可測(cè)性—— 因?yàn)?ViewModel 對(duì) View 是一無(wú)所知的，這樣我們對(duì)它的測(cè)試就變得很簡(jiǎn)單。View 應(yīng)該也是能夠被測(cè)試的，但是可能因?yàn)樗鼘?duì) UIKit 的依賴，你會(huì)直接略過(guò)它。
易用——它比MVP會(huì)更加簡(jiǎn)潔，因?yàn)樵?MVP 下你必須要把 View 的所有事件都交給 Presenter 去處理，而且需要手動(dòng)的去更新 View 的狀態(tài)；而在 MVVM 下，你只需要用綁定就可以解決。

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

為了簡(jiǎn)單易懂，以上的Demo都非常簡(jiǎn)潔，不知道看了這篇博客能否加深你對(duì)MV(X)的一些理解，這些理解也僅作為我個(gè)人的一些參考，有什么不對(duì)的地方希望大家指出。

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九欧美,1769亚洲,黄色成人av

iOS架構(gòu)模式——MV(X)的理解與實(shí)戰(zhàn)

iOS架構(gòu)模式——MV(X)的理解與實(shí)戰(zhàn)

MV(X)的基本要素

MVC

傳統(tǒng)的MVC

Apple的MVC

MVP

一些說(shuō)明：

MVVM

關(guān)于綁定

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九 欧美,1769亚洲,黄色成人av

iOS架構(gòu)模式——MV(X)的理解與實(shí)戰(zhàn)

MV(X)的基本要素

MVC

傳統(tǒng)的MVC

Apple的MVC

MVP

一些說(shuō)明：

MVVM

關(guān)于綁定

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容

色偷偷精品伊人,欧洲久久精品,欧美综合婷婷骚逼,国产AV主播,国产最新探花在线,九色在线视频一区,伊人大交九欧美,1769亚洲,黄色成人av