文章轉(zhuǎn)自: http://www.infoq.com/cn/articles/rethinking-mvc-mvvm
作者 唐巧 發(fā)布于 2015年11月1日 |
被誤解的 MVC
MVC 的歷史
MVC，全稱是 Model View Controller，是模型 (model)－視圖 (view)－控制器 (controller) 的縮寫。它表示的是一種常見的客戶端軟件開發(fā)框架。
MVC 的概念最早出現(xiàn)在二十世紀(jì)八十年代的 施樂帕克 實(shí)驗(yàn)室中（對(duì)，就是那個(gè)發(fā)明圖形用戶界面和鼠標(biāo)的實(shí)驗(yàn)室），當(dāng)時(shí)施樂帕克為 Smalltalk 發(fā)明了這種軟件設(shè)計(jì)模式。
現(xiàn)在，MVC 已經(jīng)成為主流的客戶端編程框架，在 iOS 開發(fā)中，系統(tǒng)為我們實(shí)現(xiàn)好了公共的視圖類：UIView，和控制器類：UIViewController。大多數(shù)時(shí)候，我們都需要繼承這些類來實(shí)現(xiàn)我們的程序邏輯，因此，我們幾乎逃避不開 MVC 這種設(shè)計(jì)模式。
但是，幾十年過去了，我們對(duì)于 MVC 這種設(shè)計(jì)模式真的用得好嗎？其實(shí)不是的，MVC 這種分層方式雖然清楚，但是如果使用不當(dāng)，很可能讓大量代碼都集中在 Controller 之中，讓 MVC 模式變成了 Massive View Controller 模式。
Controller 的臃腫問題何解？
很多人試圖解決 MVC 這種架構(gòu)下 Controller 比較臃腫的問題。我還記得半年前 InfoQ 搞了一次移動(dòng)座談會(huì)，當(dāng)時(shí) BeeFramework 和 Samurai-Native 的作者 老郭 問了我一句話：「什么樣的內(nèi)容才應(yīng)該放到 Controller 中？」。但是當(dāng)時(shí)因?yàn)闀r(shí)間不夠，我沒能展開我的觀點(diǎn)，這次正好在這里好好談?wù)勎覍?duì)于這個(gè)問題的想法。
我們來看看 MVC 這種架構(gòu)的特點(diǎn)。其實(shí)設(shè)計(jì)模式很多時(shí)候是為了 Don't repeat yourself 原則來做的，該原則要求能夠復(fù)用的代碼要盡量復(fù)用，來保證重用。在 MVC 這種設(shè)計(jì)模式中，我們發(fā)現(xiàn) View 和 Model 都是符合這種原則的。
對(duì)于 View 來說，你如果抽象得好，那么一個(gè) App 的動(dòng)畫效果可以很方便地移植到別的 App 上，而 Github 上也有很多 UI 控件，這些控件都是在 View 層做了很好的封裝設(shè)計(jì)，使得它能夠方便地開源給大家復(fù)用。
對(duì)于 Model 來說，它其實(shí)是用來存儲(chǔ)業(yè)務(wù)的數(shù)據(jù)的，如果做得好，它也可以方便地復(fù)用。比如我當(dāng)時(shí)在做有道云筆記 iPad 版的時(shí)候，我們就直接和 iOS 版復(fù)用了所有的 Model 層的代碼。在創(chuàng)業(yè)做猿題庫客戶端時(shí)，iOS 和 iPad 版的 Model 層代碼再次被復(fù)用上了。當(dāng)然，因?yàn)楹蜆I(yè)務(wù)本身的數(shù)據(jù)意義相關(guān)，Model 層的復(fù)用大多數(shù)是在一個(gè)產(chǎn)品內(nèi)部，不太可能像 View 層那樣開源給社區(qū)。
說完 View 和 Model 了，那我們想想 Controller，Controller 有多少可以復(fù)用的？我們寫完了一個(gè) Controller 之后，可以很方便地復(fù)用它嗎？結(jié)論是：非常難復(fù)用。在某些場(chǎng)景下，我們可能可以用addSubViewController 之類的方式復(fù)用 Controller，但它的復(fù)用場(chǎng)景還是非常非常少的。
如果我們能夠意識(shí)到 Controller 里面的代碼不便于復(fù)用，我們就能知道什么代碼應(yīng)該寫在 Controller 里面了，那就是那些不能復(fù)用的代碼。在我看來，Controller 里面就只應(yīng)該存放這些不能復(fù)用的代碼，這些代碼包括：
- 在初始化時(shí)，構(gòu)造相應(yīng)的 View 和 Model。
- 監(jiān)聽 Model 層的事件，將 Model 層的數(shù)據(jù)傳遞到 View 層。
- 監(jiān)聽 View 層的事件，并且將 View 層的事件轉(zhuǎn)發(fā)到 Model 層。
如果 Controller 只有以上的這些代碼，那么它的邏輯將非常簡(jiǎn)單，而且也會(huì)非常短。
但是，我們卻很難做到這一點(diǎn)，因?yàn)檫€是有很多邏輯我們不知道寫在哪里，于是就都寫到了 Controller 中了，那我們接下來就看看其它邏輯應(yīng)該寫在哪里。
如何對(duì) ViewController 瘦身？
objc.io 是一個(gè)非常有名的 iOS 開發(fā)博客，它上面的第一課 《Lighter View Controllers》 上就講了很多這樣的技巧，我們先總結(jié)一下它里面的觀點(diǎn)：
- 將 UITableView 的 Data Source 分離到另外一個(gè)類中。
- 將數(shù)據(jù)獲取和轉(zhuǎn)換的邏輯分別到另外一個(gè)類中。
- 將拼裝控件的邏輯，分離到另外一個(gè)類中。
你想明白了嗎？其實(shí) MVC 雖然只有三層，但是它并沒有限制你只能有三層。所以，我們可以將 Controller 里面過于臃腫的邏輯抽取出來，形成新的可復(fù)用模塊或架構(gòu)層次。
我個(gè)人對(duì)于邏輯的抽取，有以下總結(jié)。
將網(wǎng)絡(luò)請(qǐng)求抽象到單獨(dú)的類中
新手寫代碼，直接就在 Controller 里面用 AFNetworking 發(fā)一個(gè)請(qǐng)求，請(qǐng)求的完數(shù)據(jù)直接就傳遞給 View。入門一些的同學(xué)，知道把這些請(qǐng)求代碼移到另外一個(gè)靜態(tài)類里面。但是我覺得還不夠，所以我建議將每一個(gè)網(wǎng)絡(luò)請(qǐng)求直接封裝成類。
把每一個(gè)網(wǎng)絡(luò)請(qǐng)求封裝成對(duì)象其實(shí)是使用了設(shè)計(jì)模式中的 Command 模式，它有以下好處：
- 將網(wǎng)絡(luò)請(qǐng)求與具體的第三方庫依賴隔離，方便以后更換底層的網(wǎng)絡(luò)庫。實(shí)際上我們公司的 iOS 客戶端最初是基于 ASIHttpRequest 的，我們只花了兩天，就很輕松地切換到了 AFNetworking。
- 方便在基類中處理公共邏輯，例如猿題庫的數(shù)據(jù)版本號(hào)信息就統(tǒng)一在基類中處理。
- 方便在基類中處理緩存邏輯，以及其它一些公共邏輯。
- 方便做對(duì)象的持久化。
大家如果感興趣，可以看我們公司開源的 iOS 網(wǎng)絡(luò)庫：YTKNetwork。它在這種思考的指導(dǎo)下，不但將 Controller 中的代碼瘦身，而且進(jìn)一步演化和加強(qiáng)，現(xiàn)在它還支持諸如復(fù)雜網(wǎng)絡(luò)請(qǐng)求管理，斷點(diǎn)續(xù)傳，插件機(jī)制，JSON 合法性檢查等功能。
這部分代碼從 Controller 中剝離出來后，不但簡(jiǎn)化了 Controller 中的邏輯，也達(dá)到了網(wǎng)絡(luò)層的代碼復(fù)用的效果。
將界面的拼裝抽象到專門的類中
新手寫代碼，喜歡在 Controller 中把一個(gè)個(gè) UILabel ，UIButton，UITextField 往 self.view 上用 addSubView 方法放。我建議大家可以用兩種辦法把這些代碼從 Controller 中剝離。
方法一：構(gòu)造專門的 UIView 的子類，來負(fù)責(zé)這些控件的拼裝。這是最徹底和優(yōu)雅的方式，不過稍微麻煩一些的是，你需要把這些控件的事件回調(diào)先接管，再都一一暴露回 Controller。
方法二：用一個(gè)靜態(tài)的 Util 類，幫助你做 UIView 的拼裝工作。這種方式稍微做得不太徹底，但是比較簡(jiǎn)單。
對(duì)于一些能復(fù)用的 UI 控件，我建議用方法一。如果項(xiàng)目工程比較復(fù)雜，我也建議用方法一。如果項(xiàng)目太緊，另外相關(guān)項(xiàng)目的代碼量也不多，可以嘗試方法二。
構(gòu)造 ViewModel
誰說 MVC 就不能用 ViewModel 的？MVVM 的優(yōu)點(diǎn)我們一樣可以借鑒。具體做法就是將 ViewController 給 View 傳遞數(shù)據(jù)這個(gè)過程，抽象成構(gòu)造 ViewModel 的過程。
這樣抽象之后，View 只接受 ViewModel，而 Controller 只需要傳遞 ViewModel 這么一行代碼。而另外構(gòu)造 ViewModel 的過程，我們就可以移動(dòng)到另外的類中了。
在具體實(shí)踐中，我建議大家專門創(chuàng)建構(gòu)造 ViewModel 工廠類，參見 工廠模式。另外，也可以專門將數(shù)據(jù)存取都抽將到一個(gè) Service 層，由這層來提供 ViewModel 的獲取。
專門構(gòu)造存儲(chǔ)類
剛剛說到 ViewModel 的構(gòu)造可以抽獎(jiǎng)到一個(gè) Service 層。與此相應(yīng)的，數(shù)據(jù)的存儲(chǔ)也應(yīng)該由專門的對(duì)象來做。在小猿搜題項(xiàng)目中，我們由一個(gè)叫 UserAgent 的類，專門來處理本地?cái)?shù)據(jù)的存取。
數(shù)據(jù)存取放在專門的類中，就可以針對(duì)存取做額外的事情了。比如：
- 對(duì)一些熱點(diǎn)數(shù)據(jù)增加緩存
- 處理數(shù)據(jù)遷移相關(guān)的邏輯
如果要做得更細(xì)，可以把存儲(chǔ)引擎再抽象出一層。這樣你就可以方便地切換存儲(chǔ)的底層，例如從 sqlite 切換到 key-value 的存儲(chǔ)引擎等。
小結(jié)
通過代碼的抽取，我們可以將原本的 MVC 設(shè)計(jì)模式中的 ViewController 進(jìn)一步拆分，構(gòu)造出 網(wǎng)絡(luò)請(qǐng)求層、ViewModel 層、Service 層、Storage 層等其它類，來配合 Controller 工作，從而使 Controller 更加簡(jiǎn)單，我們的 App 更容易維護(hù)。
另外，不知道大家注意到?jīng)]，其實(shí) Controller 層是非常難于測(cè)試的，如果我們能夠?qū)?Controller 瘦身，就可以更方便地寫 Unit Test 來測(cè)試各種與界面的無關(guān)的邏輯。移動(dòng)端自動(dòng)化測(cè)試框架都不太成熟，但是將 Controller 的代碼抽取出來，是有助于我們做測(cè)試工作的。
希望本文能幫助大家掌握正確使用 MVC 的姿勢(shì)，在下一節(jié)里，我將分享一下我對(duì) MVVM 的看法。
被神化的 MVVM
MVVM 的歷史
MVVM 是 Model-View-ViewModel 的簡(jiǎn)寫。
相對(duì)于 MVC 的歷史來說，MVVM 是一個(gè)相當(dāng)新的架構(gòu)，MVVM 最早于 2005 年被微軟的 WPF 和 Silverlight 的架構(gòu)師 John Gossman 提出，并且應(yīng)用在微軟的軟件開發(fā)中。當(dāng)時(shí) MVC 已經(jīng)被提出了 20 多年了，可見兩者出現(xiàn)的年代差別有多大。
MVVM 在使用當(dāng)中，通常還會(huì)利用雙向綁定技術(shù)，使得 Model 變化時(shí)，ViewModel 會(huì)自動(dòng)更新，而 ViewModel 變化時(shí)，View 也會(huì)自動(dòng)變化。所以，MVVM 模式有些時(shí)候又被稱作：model-view-binder 模式。
具體在 iOS 中，可以使用 KVO 或 Notification 技術(shù)達(dá)到這種效果。
MVVM 的神化
在使用中，我發(fā)現(xiàn)大家對(duì)于 MVVM 以及 MVVM 衍生出來的框架（比如 ReactiveCocoa）有一種「敬畏」感。這種「敬畏」感某種程度上就像對(duì)神一樣，這主要表現(xiàn)在我沒有聽到大家對(duì)于 MVVM 的任何批評(píng)。
我感覺原因首先是 MVVM 并沒有很大程度上普及，大家對(duì)于新技術(shù)一般都不熟，進(jìn)而不敢妄加評(píng)論。另外，ReactiveCocoa 本身上手的復(fù)雜性，也讓很多人感覺到這種技術(shù)很高深難懂，進(jìn)而加重了大家對(duì)它的「敬畏」。
MVVM 的作用和問題
MVVM 在實(shí)際使用中，確實(shí)能夠使得 Model 層和 View 層解耦，但是如果你需要實(shí)現(xiàn) MVVM 中的雙向綁定的話，那么通常就需要引入更多復(fù)雜的框架來實(shí)現(xiàn)了。
對(duì)此，MVVM 的作者 John Gossman 的 批評(píng) 應(yīng)該是最為中肯的。John Gossman 對(duì) MVVM 的批評(píng)主要有兩點(diǎn)：
第一點(diǎn)：數(shù)據(jù)綁定使得 Bug 很難被調(diào)試。你看到界面異常了，有可能是你 View 的代碼有 Bug，也可能是 Model 的代碼有問題。數(shù)據(jù)綁定使得一個(gè)位置的 Bug 被快速傳遞到別的位置，要定位原始出問題的地方就變得不那么容易了。
第二點(diǎn)：對(duì)于過大的項(xiàng)目，數(shù)據(jù)綁定需要花費(fèi)更多的內(nèi)存。
某種意義上來說，我認(rèn)為就是數(shù)據(jù)綁定使得 MVVM 變得復(fù)雜和難用了。但是，這個(gè)缺點(diǎn)同時(shí)也被很多人認(rèn)為是優(yōu)點(diǎn)。
ReactiveCocoa
函數(shù)式編程（Functional Programming）和響應(yīng)式編程（React Programming）也是當(dāng)前很火的兩個(gè)概念，它們的結(jié)合可以很方便地實(shí)現(xiàn)數(shù)據(jù)的綁定。于是，在 iOS 編程中，ReactiveCocoa 橫空出世了，它的概念都非常 新，包括：
- 函數(shù)式編程（Functional Programming），函數(shù)也變成一等公民了，可以擁有和對(duì)象同樣的功能，例如當(dāng)成參數(shù)傳遞，當(dāng)作返回值等。看看 Swift 語言帶來的眾多函數(shù)式編程的特性，就你知道這多 Cool 了。
- 響應(yīng)式編程（React Programming），原來我們基于事件（Event）的處理方式都弱了，現(xiàn)在是基于輸入（在 ReactiveCocoa 里叫 Signal）的處理方式。輸入還可以通過函數(shù)式編程進(jìn)行各種 Combine 或 Filter，盡顯各種靈活的處理。
- 無狀態(tài)（Stateless），狀態(tài)是函數(shù)的魔鬼，無狀態(tài)使得函數(shù)能更好地測(cè)試。
- 不可修改（Immutable），數(shù)據(jù)都是不可修改的，使得軟件邏輯簡(jiǎn)單，也可以更好地測(cè)試。
哇，所有這些都太 Cool 了。當(dāng)我看到的時(shí)候，我都雞凍了！
我們應(yīng)該客觀評(píng)價(jià) MVVM 和 ReactiveCocoa
但是但是，我突然想到，我好象只需要一個(gè) ViewModel 而已，我完全可以簡(jiǎn)單地做一個(gè) ViewModel 的工廠類或 Service 類就可以了，為什么要引入這么多框架？現(xiàn)有的 MVC 真的有那么大的問題嗎？
直到現(xiàn)在，ReactiveCocoa 在國(guó)內(nèi)外還都是在小眾領(lǐng)域，沒有被大量接受成為主流的編程框架。不只是在 iOS 語言，在別的語言中，例如 Java 中的 RxJava 也同樣沒有成為主流。
我在這里，不是想說 ReactiveCocoa 不好，也不是想說 MVVM 不好，而是想讓大家都能夠有一個(gè)客觀的認(rèn)識(shí)。ReactiveCocoa 和 MVVM 不應(yīng)該被神化，它是一種新穎的編程框架，能夠解決舊有編程框架的一些問題，但是也會(huì)帶來一些新問題，僅此而已。如果不能使好的駕馭 ReactiveCocoa，同樣會(huì)造成 Controller 代碼過于復(fù)雜，代碼邏輯不易維護(hù)的問題。
總結(jié)
有一些人總是追趕著技術(shù)，有什么新技術(shù)不管三七二十一立馬就用，結(jié)果被各種坑。
又有一些人，總是擔(dān)心新技術(shù)帶來的技術(shù)風(fēng)險(xiǎn)，不愿意學(xué)習(xí)。結(jié)果現(xiàn)在還有人在用 MRC 手動(dòng)管理引用計(jì)數(shù)。
而我想說，我們需要保持的是一個(gè)擁抱變化的心，以及理性分析的態(tài)度。在新技術(shù)的面前，不盲從，也不守舊，一切的決策都應(yīng)該建立在認(rèn)真分析的基礎(chǔ)上，這樣才能應(yīng)對(duì)技術(shù)的變化。
文章轉(zhuǎn)自: http://www.infoq.com/cn/articles/rethinking-mvc-mvvm
作者 唐巧 發(fā)布于 2015年11月1日 |
