一、概述
在 iOS 開發(fā)中，MVC（Model View Controller）是構(gòu)建iOS App的標(biāo)準(zhǔn)模式，是蘋果推薦的一個用來組織代碼的權(quán)威范式。Apple甚至是這么說的。在MVC下，所有的對象被歸類為一個Model，一個View，和一個Controller。Model持有數(shù)據(jù)，View顯示與用戶交互的界面，而ViewController調(diào)解Model和View之間的交互。現(xiàn)在，MVC 依然是目前主流客戶端編程框架，但同時它也被調(diào)侃成Massive View Controller（重量級視圖控制器），想必開發(fā)者在開發(fā)中無可避免被下面幾個問題所困擾：
厚重的ViewController
遺失的網(wǎng)絡(luò)邏輯（無立足之地）
較差的可測試性
為了避免和解決上述問題的產(chǎn)生，從MVC引申出來一種維護(hù)性較強(qiáng)、耦合性低的新的架構(gòu)MVVM（Model View View-Mode），MVVM正式規(guī)范了視圖和控制器緊耦合的性質(zhì)，并引入新的組件。MVVM主要目的是為了分離視圖（View）和模型（Model）。
二、MVC（Model View Controller）
1.MVC之間的關(guān)系
任何一個正經(jīng)開發(fā)過軟件的人都熟悉MVC，它意思是Model View Controller, 是一個在復(fù)雜應(yīng)用設(shè)計中組織代碼的公認(rèn)模式，它們之間的結(jié)構(gòu)關(guān)系如下：
我們看到的只是一個蘋果?典型的MVC?設(shè)置。view將用戶交互通知給controller。view controller通過更新model來反應(yīng)狀態(tài)的改變。model（通常使用Key-Value-Observation）通知controller來更新他們負(fù)責(zé)的view。大多數(shù)iOS應(yīng)用程序的代碼使用這種方式來組織。然而，典型的MVC架構(gòu)不適用于當(dāng)下的iOS開發(fā)。盡管從技術(shù)上看View?和?Controller?是相互獨(dú)立的，但事實(shí)上它們幾乎總是結(jié)對出現(xiàn)，一個?View?只能與一個?Controller?進(jìn)行匹配，反之亦然。既然如此，那我們?yōu)楹尾徽?guī)化它們的連接：
因此，M-VC?可能是對 iOS 開發(fā)中的?MVC模式更為準(zhǔn)確的解讀，同時更也準(zhǔn)確地描述了我們?nèi)粘ｉ_發(fā)可能已經(jīng)編寫的?MVC?代碼，但它并沒有做太多事情來解決 iOS 應(yīng)用中日益增長的重量級視圖控制器的問題。
2.MVC的弊端
MVC的利弊大家想必是有目共睹的，Massive View Controller的說法也并非空穴來風(fēng)的。讓我們一起探討MVC的弊端，剖析問題產(chǎn)生原因，打造一個輕量級的ViewController，明確MVC設(shè)計模式中各個角色的職責(zé)。
厚重的View Controller
M：模型model的對象通常非常的簡單。根據(jù)Apple的文檔，model應(yīng)包括數(shù)據(jù)和操作數(shù)據(jù)的業(yè)務(wù)邏輯。而在實(shí)踐中，model層往往非常薄，不管怎樣，model層的業(yè)務(wù)邏輯不應(yīng)被拖入到controller。
V：視圖view通常是UIKit控件（component，這里根據(jù)習(xí)慣譯為控件）或者編碼定義的UIKit控件的集合。View的如何構(gòu)建（PS：IB或者手寫界面）何必讓Controller知曉，同時View不應(yīng)該直接引用model（PS：現(xiàn)實(shí)中，你懂的?。?，并且僅僅通過IBAction事件引用controller。業(yè)務(wù)邏輯很明顯不歸入view，視圖本身沒有任何業(yè)務(wù)。
C：控制器controller。Controller是app的“膠水代碼”：協(xié)調(diào)模型和視圖之間的所有交互。控制器負(fù)責(zé)管理他們所擁有的視圖的視圖層次結(jié)構(gòu)，還要響應(yīng)視圖的loading、appearing、disappearing等等，同時往往也會充滿我們不愿暴露的model的模型邏輯以及不愿暴露給視圖的業(yè)務(wù)邏輯。
網(wǎng)絡(luò)數(shù)據(jù)的請求及后續(xù)處理，本地數(shù)據(jù)庫操作，以及一些帶有工具性質(zhì)輔助方法都加大了Massive View Controller的產(chǎn)生。
遺失（無處安放）的網(wǎng)絡(luò)邏輯
蘋果使用的MVC的定義是這么說的：所有的對象都可以被歸類為一個model，一個view，或是一個controller。
你可能試著把它放在Model對象里，但是也會很棘手，因?yàn)榫W(wǎng)絡(luò)調(diào)用應(yīng)該使用異步，這樣如果一個網(wǎng)絡(luò)請求比持有它的model生命周期更長，事情將變的復(fù)雜。顯然View里面做網(wǎng)絡(luò)請求那就更格格不入了，因此只剩下Controller了。若這樣，這又加劇了Massive View Controller的問題。若不這樣，何處才是網(wǎng)絡(luò)邏輯的家呢？
較差的可測試性
由于View Controller混合了視圖處理邏輯和業(yè)務(wù)邏輯，分離這些成分的單元測試成了一個艱巨的任務(wù)。若一個Massive View Controller有上萬行代碼，要你編寫個單元測試，我敢保證，你不是想寫，你是想死，分分鐘填表走人。
三、MVVM（Model View View-Mode）
一種可以很好地解決Massive View Controller問題的辦法就是將?Controller?中的展示邏輯抽取出來，放置到一個專門的地方，而這個地方就是?viewModel?。MVVM衍生于MVC，是對?MVC?的一種演進(jìn)，它促進(jìn)了 UI 代碼與業(yè)務(wù)邏輯的分離。它正式規(guī)范了視圖和控制器緊耦合的性質(zhì)，并引入新的組件。他們之間的結(jié)構(gòu)關(guān)系如下：
1:MVVM 的基本概念
在MVVM?中，view?和?view controller正式聯(lián)系在一起，我們把它們視為一個組件
view?和?view controller?都不能直接引用model，而是引用視圖模型（viewModel）
viewModel?是一個放置用戶輸入驗(yàn)證邏輯，視圖顯示邏輯，發(fā)起網(wǎng)絡(luò)請求和其他代碼的地方
使用MVVM會輕微的增加代碼量，但總體上減少了代碼的復(fù)雜性
2:MVVM 的注意事項
view?引用viewModel?，但反過來不行（即不要在viewModel中引入#import UIKit.h，任何視圖本身的引用都不應(yīng)該放在viewModel中）（PS：基本要求，必須滿足）
viewModel?引用model，但反過來不行
3:MVVM 的使用建議
MVVM?可以兼容你當(dāng)下使用的MVC架構(gòu)。
MVVM?增加你的應(yīng)用的可測試性。
MVVM?配合一個綁定機(jī)制效果最好（PS：ReactiveCocoa你值得擁有）。
viewController?盡量不涉及業(yè)務(wù)邏輯，讓?viewModel?去做這些事情。
viewController?只是一個中間人，接收?view?的事件、調(diào)用?viewModel?的方法、響應(yīng)?viewModel?的變化。
viewModel?絕對不能包含視圖?view（UIKit.h），不然就跟?view?產(chǎn)生了耦合，不方便復(fù)用和測試。
viewModel之間可以有依賴。
viewModel避免過于臃腫，否則重蹈Controller的覆轍，變得難以維護(hù)。
4:MVVM 的優(yōu)勢
低耦合：View?可以獨(dú)立于Model變化和修改，一個?viewModel?可以綁定到不同的?View?上
可重用性：可以把一些視圖邏輯放在一個?viewModel里面，讓很多?view?重用這段視圖邏輯
獨(dú)立開發(fā)：開發(fā)人員可以專注于業(yè)務(wù)邏輯和數(shù)據(jù)的開發(fā)?viewModel，設(shè)計人員可以專注于頁面設(shè)計
可測試：通常界面是比較難于測試的，而?MVVM?模式可以針對?viewModel來進(jìn)行測試
5:MVVM 的弊端
數(shù)據(jù)綁定使得Bug?很難被調(diào)試。你看到界面異常了，有可能是你?View?的代碼有?Bug，也可能是?Model?的代碼有問題。數(shù)據(jù)綁定使得一個位置的?Bug?被快速傳遞到別的位置，要定位原始出問題的地方就變得不那么容易了。
對于過大的項目，數(shù)據(jù)綁定和數(shù)據(jù)轉(zhuǎn)化需要花費(fèi)更多的內(nèi)存（成本）。主要成本在于：
數(shù)組內(nèi)容的轉(zhuǎn)化成本較高：數(shù)組里面每項都要轉(zhuǎn)化成Item對象，如果Item對象中還有類似數(shù)組，就很頭疼。
轉(zhuǎn)化之后的數(shù)據(jù)在大部分情況是不能直接被展示的，為了能夠被展示，還需要第二次轉(zhuǎn)化。
只有在API返回的數(shù)據(jù)高度標(biāo)準(zhǔn)化時，這些對象原型（Item）的可復(fù)用程度才高，否則容易出現(xiàn)類型爆炸，提高維護(hù)成本。
調(diào)試時通過對象原型查看數(shù)據(jù)內(nèi)容不如直接通過NSDictionary/NSArray直觀。
同一API的數(shù)據(jù)被不同View展示時，難以控制數(shù)據(jù)轉(zhuǎn)化的代碼，它們有可能會散落在任何需要的地方。
四、總結(jié)
MVC的設(shè)計模式也并非是病入膏肓，無藥可救的架構(gòu)，最起碼目前MVC設(shè)計模式仍舊是iOS開發(fā)的主流框架，存在即合理。針對文章所述的弊端，我們依舊有許多可行的方法去避免和解決，從而打造一個輕量級的ViewController。
MVVM是MVC的升級版，完全兼容當(dāng)前的MVC架構(gòu)，MVVM雖然促進(jìn)了UI 代碼與業(yè)務(wù)邏輯的分離，一定程度上減輕了ViewController的臃腫度，但是View和ViewModel之間的數(shù)據(jù)綁定使得?MVVM變得復(fù)雜和難用了，如果我們不能更好的駕馭兩者之間的數(shù)據(jù)綁定，同樣會造成Controller?代碼過于復(fù)雜，代碼邏輯不易維護(hù)的問題。
一個輕量級的ViewController是基于MVC和MVVM模式進(jìn)行代碼職責(zé)的分離而打造的。MVC和MVVM有優(yōu)點(diǎn)也有缺點(diǎn)，但缺點(diǎn)在他們所帶來的好處面前時不值一提的。他們的低耦合性，封裝性，可測試性，可維護(hù)性和多人協(xié)作便利大大提高了開法效率。
同時，我們需要保持的是一個擁抱變化的心，以及理性分析的態(tài)度。在新技術(shù)的面前，不盲從，也不守舊，一切的決策都應(yīng)該建立在認(rèn)真分析的基礎(chǔ)上，這樣才能應(yīng)對技術(shù)的變化。
五、期待
文章若對您有點(diǎn)幫助，請給個喜歡??，畢竟碼字不易；若對您沒啥幫助，請給點(diǎn)建議????，切記學(xué)無止境。
