摘要：所以我查了很多的材料，希望能從自己的角度上用通俗的語(yǔ)言闡述前端框架的演變。現(xiàn)在，前端頁(yè)面會(huì)有很多復(fù)雜的交互邏輯和用戶體驗(yàn)，如果還使用之前老的框架，對(duì)層的操作就會(huì)難以維護(hù)，這就是前端框架要不斷演變的主要原因。

說(shuō)實(shí)在的，我不覺得MVC，MVVM這些框架有什么難的，直到我想寫一篇文章去系統(tǒng)的闡述它們。我遇到了以下幾個(gè)問(wèn)題，1.不同的文章說(shuō)的南轅北轍 2.沒(méi)有一個(gè)清晰的大綱和框架分類。所以我查了很多的材料，希望能從自己的角度上用通俗的語(yǔ)言闡述前端框架的演變。

演變目的: 用簡(jiǎn)單的方法處理越來(lái)越復(fù)雜的View層

在最開始的時(shí)候，View層是很簡(jiǎn)單的，甚至都沒(méi)有什么畫面；而隨著信息時(shí)代的發(fā)展，它變得越來(lái)越復(fù)雜。現(xiàn)在，前端頁(yè)面會(huì)有很多復(fù)雜的交互邏輯和用戶體驗(yàn)，如果還使用之前老的框架，對(duì)View層的操作就會(huì)難以維護(hù)，這就是前端框架要不斷演變的主要原因。

框架分類：討論框架一定要結(jié)合應(yīng)用場(chǎng)景和歷史背景

上世紀(jì)70年代，MVC誕生。最初是應(yīng)用在GUI程序（圖形界面程序）上，而不是WEB程序上——對(duì)于這種MVC，我們稱之為經(jīng)典MVC。后來(lái)，在WEB程序上的MVC都是經(jīng)典MVC的變體；而且，WEB程序上后端MVC和前端MVC也會(huì)有些許區(qū)別。因此，不區(qū)分應(yīng)用場(chǎng)景和歷史背景，就把經(jīng)典MVC和WEB MVC混做一團(tuán)是非常不負(fù)責(zé)任的。

另外，不管MVC，MVP，MVVM以及它們諸多的變體MVX，本質(zhì)上都是三層的結(jié)構(gòu)。

Model管理數(shù)據(jù)和業(yè)務(wù)邏輯

View渲染頁(yè)面

X負(fù)責(zé)二者之間的聯(lián)系

回想我們?cè)谖恼碌谝徊糠志椭靥岬降?，演變的最終目的就是為了適應(yīng)越來(lái)越復(fù)雜的View層，讓我們一直記著這句話來(lái)看下面的內(nèi)容。

第二部分已經(jīng)提到過(guò)了，因?yàn)镸VC變種眾多，不結(jié)合應(yīng)用場(chǎng)景和歷史背景的討論都是耍流氓。

在上世紀(jì)70年代，因?yàn)闆](méi)有操作系統(tǒng)和消息循環(huán)，甚至鼠標(biāo)的光標(biāo)都需要我們的UI系統(tǒng)來(lái)自行繪制，所以這時(shí)候用戶的輸入是由Controller來(lái)獲得的[1]。Controller獲得用戶的輸入之后，去調(diào)用相應(yīng)的Model修改數(shù)據(jù)，同時(shí)修改View響應(yīng)用戶的輸入。Model的數(shù)據(jù)修改之后，會(huì)通知相關(guān)的View。View監(jiān)聽Model，當(dāng)收到通知后，就修改樣式。

調(diào)用關(guān)系如下[2]：

我們可以看到，WEB MVC和經(jīng)典MVC本質(zhì)上是一樣的，同樣都擁有了Controller去修改Model的調(diào)用關(guān)系。但是，它們之間有兩個(gè)區(qū)別：

用戶輸入從Controller變?yōu)榱薞iew：View承接了部分controller的功能，負(fù)責(zé)處理用戶輸入，但是不必了解下一步做什么。它依賴于一個(gè)controller為她做決定或處理用戶事件。

Controller的作用變?。涸诮?jīng)典MVC中，“Controller是用戶和系統(tǒng)之間的鏈接”，但是在WEB MVC中，View既可以委托Controller對(duì)Model進(jìn)行修改，也可以獨(dú)立處理用戶事件。在經(jīng)典MVC中，Controller要做的事情多數(shù)是派發(fā)用戶輸入給不同的View，而這部分工作在WEB MVC中已經(jīng)被系統(tǒng)做了。[3]因此，在WEB MVC中，Controller變得很薄，只剩下一些驗(yàn)證輸入和路由的工作。

優(yōu)點(diǎn)：

把業(yè)務(wù)邏輯和展示邏輯分離，模塊化程度高。且當(dāng)應(yīng)用邏輯需要變更的時(shí)候，不需要變更業(yè)務(wù)邏輯和展示邏輯，只需要Controller換成另外一個(gè)Controller就行了。

觀察者模式可以做到多視圖同時(shí)更新。

缺點(diǎn)：

Controller測(cè)試?yán)щy。因?yàn)橐晥D同步操作是由View自己執(zhí)行，而View只能在有UI的環(huán)境下運(yùn)行。在沒(méi)有UI環(huán)境下對(duì)Controller進(jìn)行單元測(cè)試的時(shí)候，應(yīng)用邏輯正確性是無(wú)法驗(yàn)證的：Model更新的時(shí)候，無(wú)法對(duì)View的更新操作進(jìn)行斷言。

View無(wú)法組件化。View是強(qiáng)依賴特定的Model的，如果需要把這個(gè)View抽出來(lái)作為一個(gè)另外一個(gè)應(yīng)用程序可復(fù)用的組件就困難了。因?yàn)椴煌绦虻牡腄omain Model是不一樣的。[1]

感謝前端的前輩們，我們并沒(méi)有在MVP階段多做逗留，而是大步進(jìn)入了MVVM階段。其實(shí)MVP和MVVM的主要區(qū)別就是在于是否有雙向數(shù)據(jù)綁定。有興趣的可以看《淺析 MVC, MVP 與 MVVM之間的異同》自行了解。

在3.2我們實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的MVC，設(shè)想一下，現(xiàn)在頁(yè)面上不是只有一個(gè)按鈕，而是有1000個(gè)按鈕，每個(gè)按鈕還要操作不同的DOM對(duì)象，因?yàn)镸VC是無(wú)法組件化的，這時(shí)View的邏輯就會(huì)變得非常的復(fù)雜和難以維護(hù)。為了解決這個(gè)問(wèn)題，MVVM就應(yīng)運(yùn)而生了。

用戶與View交互，觸發(fā)用戶事件；View根據(jù)事件類型調(diào)用ViewModel中對(duì)應(yīng)的響應(yīng)邏輯；然后ViewModel中的響應(yīng)邏輯在做完適當(dāng)處理后，會(huì)去調(diào)用Model層的接口；接口的調(diào)用執(zhí)行，導(dǎo)致Model層數(shù)據(jù)的變化，進(jìn)而觸發(fā)相應(yīng)的數(shù)據(jù)改變事件；事件又被ViewModel模塊監(jiān)聽到；拿到新的Model數(shù)據(jù)，ViewModel中的展示邏輯會(huì)去修改ViewModel中的狀態(tài)數(shù)據(jù)；ViewModel中狀態(tài)數(shù)據(jù)的改變，最終引起View的狀態(tài)變換，完成了這次對(duì)用戶事件的響應(yīng)。

優(yōu)點(diǎn)：

組件化。View不依賴Model。這樣就可以讓View從特定的業(yè)務(wù)場(chǎng)景中脫離出來(lái)，從而撰寫高度可復(fù)用的組件 。

提高可維護(hù)性。解決了MVP大量的手動(dòng)View和Model同步的問(wèn)題，提供雙向綁定機(jī)制。因?yàn)橥竭壿嬍墙挥葿inder做的，View跟著Model同時(shí)變更，所以只需要保證Model的正確性，View就正確。大大減少了對(duì)View同步更新的測(cè)試。

缺點(diǎn)：

過(guò)于簡(jiǎn)單的圖形界面不適用

《前端設(shè)計(jì)模式》

《淺析 MVC, MVP 與 MVVM之間的異同》

《界面之下，還原真實(shí)的MV*》

《前端MVC變形記》

《MVC wiki》

《談?wù)刄I架構(gòu)設(shè)計(jì)的演化》

《MVC,MVP,MVVM的圖示》