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

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

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

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

模型（Model）用于封裝與應用程序的業(yè)務邏輯相關的數(shù)據(jù)以及對數(shù)據(jù)的處理方法。“ Model ”有對數(shù)據(jù)直接訪問的權力，“Model”不依賴“View”和“Controller”，Model 不關心它會被如何顯示或是如何被操作。但是 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），因此應該事先在被它監(jiān)視的數(shù)據(jù)那里注冊。

控制器（Controller）起到不同層面間的組織作用，用于控制應用程序的流程。它處理事件并作出響應。“事件”包括用戶的行為和數(shù)據(jù) Model 上的改變。

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

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

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

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

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

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

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

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

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

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

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

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

Model層：數(shù)據(jù)模型與持久化抽象模型。數(shù)據(jù)模型很好理解，就是從服務器拉回來的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的差異不是很大。

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

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