投身IT江湖，就像打王者榮耀一樣，好不容易練會(huì)了一個(gè)硬性，結(jié)果天美把它削弱了，你不得不再去練習(xí)一個(gè)。

MVC這門技術(shù)伴隨著我的成長(zhǎng)，感情和Java一樣深厚，但是，最近兩年卻不得不和MVC說(shuō)再見(jiàn)了。是的，不是Struts沒(méi)了，也不是SpringMVC沒(méi)了，而是MVC這種架構(gòu)模式被淘汰了。當(dāng)時(shí)代拋棄你時(shí)，連一聲再見(jiàn)都不會(huì)說(shuō)。所以，看到這篇文章的各位程序員兄弟們，緊跟技術(shù)發(fā)展趨勢(shì)，再牛逼一點(diǎn)的，能夠提前預(yù)見(jiàn)技術(shù)趨勢(shì)，提前準(zhǔn)備，最牛逼的，引領(lǐng)技術(shù)趨勢(shì)，咳咳，想的有點(diǎn)多。

我們先回顧一下MVC吧，就像懷念一個(gè)老朋友。

MVC模式（Model–view–controller）是軟件工程中的一種軟件架構(gòu)模式，把軟件系統(tǒng)分為三個(gè)基本部分：模型（Model）、視圖（View）和控制器（Controller）。( 摘自 維基百科-MVC )

模型（Model）用于封裝與應(yīng)用程序的業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù)以及對(duì)數(shù)據(jù)的處理方法?！?Model ”有對(duì)數(shù)據(jù)直接訪問(wèn)的權(quán)力，“Model”不依賴“View”和“Controller”，Model 不關(guān)心它會(huì)被如何顯示或是如何被操作。但是 Model 中數(shù)據(jù)的變化一般會(huì)通過(guò)一種刷新機(jī)制被公布。為了實(shí)現(xiàn)這種機(jī)制，那些用于監(jiān)視此 Model 的 View 必須事先在此 Model 上注冊(cè)，從而，View 可以了解在數(shù)據(jù) Model 上發(fā)生的改變。

視圖（View）能夠?qū)崿F(xiàn)數(shù)據(jù)有目的的顯示。在 View 中一般沒(méi)有程序上的邏輯。為了實(shí)現(xiàn) View 上的刷新功能，View 需要訪問(wèn)它監(jiān)視的數(shù)據(jù)模型（Model），因此應(yīng)該事先在被它監(jiān)視的數(shù)據(jù)那里注冊(cè)。

控制器（Controller）起到不同層面間的組織作用，用于控制應(yīng)用程序的流程。它處理事件并作出響應(yīng)?！笆录卑ㄓ脩舻男袨楹蛿?shù)據(jù) Model 上的改變。

Struts和SpringMVC曾經(jīng)是MVC雙雄。

那是什么導(dǎo)致MVC模式被淘汰了呢？移動(dòng)時(shí)代的到來(lái)，展示端愈來(lái)愈重要，所以前端技術(shù)發(fā)展越來(lái)越猛烈，前端工程師也不再是團(tuán)隊(duì)的小弟了，他們要求和Java工程師平等對(duì)話。

前后端分離來(lái)了，Node.js來(lái)了，前端工程師把MVC的職責(zé)都給搶走了，后端工程師真正成為了后端，只需要提供API給前端就行，再也不用關(guān)心redirectforward有什么區(qū)別，再也不用關(guān)心session、cookies有什么區(qū)別，怎么樣。當(dāng)前端工程師拿走M(jìn)VC的職責(zé)之后，自然會(huì)把MVC模式改成更適合前端的模式：MVVM。

MVVM（Model–View–Viewmodel）也是一種軟件架構(gòu)模式，它必將取代MVC，或者說(shuō)的好聽(tīng)一些，它是MVC基礎(chǔ)上演化而來(lái)。

MVC中的M就是單純的從網(wǎng)絡(luò)獲取回來(lái)的數(shù)據(jù)模型，V指的我們的視圖界面，而C就是我們的ViewController。

在其中，ViewController負(fù)責(zé)View和Model之間調(diào)度，View發(fā)生交互事件會(huì)通過(guò)target-action或者delegate方式回調(diào)給ViewController，與此同時(shí)ViewController還要承擔(dān)把Model通過(guò)KVO、Notification方式傳來(lái)的數(shù)據(jù)傳輸給View用于展示的責(zé)任。隨著業(yè)務(wù)越來(lái)越復(fù)雜，視圖交互越復(fù)雜，導(dǎo)致Controller越來(lái)越臃腫，負(fù)重前行。臟活累活都它干了，到頭來(lái)還一點(diǎn)不討好。福報(bào)修多了的結(jié)果就是，不行了就重構(gòu)你，重構(gòu)不了就換掉你。

來(lái)一張斯坦福老頭經(jīng)典的MVC架構(gòu)圖。

所以為了解決這個(gè)問(wèn)題，MVVM就閃亮登場(chǎng)了。他把View和Contrller都放在了View層（相當(dāng)于把Controller一部分邏輯抽離了出來(lái)），Model層依然是服務(wù)端返回的數(shù)據(jù)模型。而ViewModel充當(dāng)了一個(gè)UI適配器的角色，也就是說(shuō)View中每個(gè)UI元素都應(yīng)該在ViewModel找到與之對(duì)應(yīng)的屬性。除此之外，從Controller抽離出來(lái)的與UI有關(guān)的邏輯都放在了ViewModel中，這樣就減輕了Controller的負(fù)擔(dān)。

這張圖是從網(wǎng)上找的，MVVM還在學(xué)習(xí)階段，后續(xù)補(bǔ)一張自己的

從以上的架構(gòu)圖中，我們可以很清晰的梳理出各自的分工。

View層：視圖展示。包含UIView以及UIViewController，View層是可以持有ViewModel的。

ViewModel層：視圖適配器。暴露屬性與View元素顯示內(nèi)容或者元素狀態(tài)一一對(duì)應(yīng)。一般情況下ViewModel暴露的屬性建議是readOnly的，至于為什么，我們?cè)趯?shí)戰(zhàn)中會(huì)去解釋。還有一點(diǎn)，ViewModel層是可以持有Model的。

Model層：數(shù)據(jù)模型與持久化抽象模型。數(shù)據(jù)模型很好理解，就是從服務(wù)器拉回來(lái)的JSON數(shù)據(jù)。而持久化抽象模型暫時(shí)放在Model層，是因?yàn)镸VVM誕生之初就沒(méi)有對(duì)這塊進(jìn)行很細(xì)致的描述。按照經(jīng)驗(yàn)，我們通常把數(shù)據(jù)庫(kù)、文件操作封裝成Model，并對(duì)外提供操作接口。（有些公司把數(shù)據(jù)存取操作單拎出來(lái)一層，稱之為DataAdapter層，所以在業(yè)內(nèi)會(huì)有很多MVVM的變種，但其本質(zhì)上都是MVVM）。

Binder：MVVM的靈魂。可惜在MVVM這幾個(gè)英文單詞中并沒(méi)有它的一席之地，它的最主要作用是在View和ViewModel之間做了雙向數(shù)據(jù)綁定。如果MVVM沒(méi)有Binder，那么它與MVC的差異不是很大。

總結(jié)來(lái)說(shuō)，MVC模式本來(lái)是完美的，但是隨著移動(dòng)時(shí)代的到來(lái)，前端數(shù)據(jù)展示、交互、跳轉(zhuǎn)變得復(fù)雜了，Controller的只能真的不適合在放到后端了，所以MVVM就出現(xiàn)了。

后面的文章中會(huì)繼續(xù)闡述MVVM、SPA等前端的架構(gòu)模型，就像練一個(gè)天美的新英雄一樣。