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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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