本文來(lái)自http://blog.sina.com.cn/s/blog_ea7f3fd70102webk.html

MVVM 的歷史

MVVM是 Model-View-ViewModel 的簡(jiǎn)寫(xiě)。

相對(duì)于 MVC 的歷史來(lái)說(shuō)，MVVM 是一個(gè)相當(dāng)新的架構(gòu)，MVVM 最早于 2005 年被微軟的 WPF 和 Silverlight 的架構(gòu)師 John Gossman 提出，并且應(yīng)用在微軟的軟件開(kāi)發(fā)中。當(dāng)時(shí) MVC 已經(jīng)被提出了 20 多年了，可見(jiàn)兩者出現(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 衍生出來(lái)的框架（如 ReactiveCocoa

）有一種「敬畏」感。這種「敬畏」感某種程度上就像對(duì)神一樣，這主要表現(xiàn)在我沒(méi)有聽(tīng)到大家對(duì)于 MVVM 的任何批評(píng)。

我感覺(jué)原因首先是 MVVM 并沒(méi)有很大程度上普及，大家對(duì)于新技術(shù)一般都不熟，進(jìn)而不敢妄加評(píng)論。另外，ReactiveCocoa 本身上手的復(fù)雜性，也讓很多人感覺(jué)到這種技術(shù)很高深難懂，進(jìn)而加重了大家對(duì)它的「敬畏」。

MVVM 的作用和問(wèn)題

MVVM 在實(shí)際使用中，確實(shí)能夠使得 Model 層和 View 層解耦，但是如果你需要實(shí)現(xiàn) MVVM 中的雙向綁定的話，那么通常就需要引入更多復(fù)雜的框架來(lái)實(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 的代碼有問(wèn)題。數(shù)據(jù)綁定使得一個(gè)位置的 Bug 被快速傳遞到別的位置，要定位原始出問(wèn)題的地方就變得不那么容易了。

第二點(diǎn)：對(duì)于過(guò)大的項(xiàng)目，數(shù)據(jù)綁定需要花費(fèi)更多的內(nèi)存。

某種意義上來(lái)說(shuō)，我認(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 語(yǔ)言帶來(lái)的眾多函數(shù)式編程的特性，就你知道這多 Cool 了。

響應(yīng)式編程（React Programming），原來(lái)我們基于事件（Event）的處理方式都弱了，現(xiàn)在是基于輸入（在 ReactiveCocoa 里叫 Signal）的處理方式。輸入還可以通過(guò)函數(shù)式編程進(jìn)行各種 Combine 或 Filter，盡顯各種靈活的處理。

無(wú)狀態(tài)（Stateless），狀態(tài)是函數(shù)的魔鬼，無(wú)狀態(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 真的有那么大的問(wèn)題嗎？

直到現(xiàn)在，ReactiveCocoa 在國(guó)內(nèi)外還都是在小眾領(lǐng)域，沒(méi)有被大量接受成為主流的編程框架。不只是在 iOS 語(yǔ)言，在別的語(yǔ)言中，例如 Java 中的 RxJava 也同樣沒(méi)有成為主流。

我在這里，不是想說(shuō) ReactiveCocoa 不好，也不是想說(shuō) MVVM 不好，而是想讓大家都能夠有一個(gè)客觀的認(rèn)識(shí)。ReactiveCocoa 和 MVVM 不應(yīng)該被神化，它是一種新穎的編程框架，能夠解決舊有編程框架的一些問(wèn)題，但是也會(huì)帶來(lái)一些新問(wèn)題，僅此而已。如果不能使好的駕馭 ReactiveCocoa，同樣會(huì)造成 Controller 代碼過(guò)于復(fù)雜，代碼邏輯不易維護(hù)的問(wèn)題。

總結(jié)

有一些人總是追趕著技術(shù)，有什么新技術(shù)不管三七二十一立馬就用，結(jié)果被各種坑。

又有一些人，總是擔(dān)心新技術(shù)帶來(lái)的技術(shù)風(fēng)險(xiǎn)，不愿意學(xué)習(xí)。結(jié)果現(xiàn)在還有人在用 MRC 手動(dòng)管理引用計(jì)數(shù)。

而我想說(shuō)，我們需要保持的是一個(gè)擁抱變化的心，以及理性分析的態(tài)度。在新技術(shù)的面前，不盲從，也不守舊，一切的決策都應(yīng)該建立在認(rèn)真分析的基礎(chǔ)上，這樣才能應(yīng)對(duì)技術(shù)的變化。