一篇文章瞭解前端框架演變

說實在的，我不以爲MVC，MVVM這些框架有什麼難的，直到我想寫一篇文章去系統的闡述它們。我遇到了如下幾個問題，1.不一樣的文章說的南轅北轍 2.沒有一個清晰的大綱和框架分類。因此我查了不少的材料，但願能從本身的角度上用通俗的語言闡述前端框架的演變。

1 演變的目的

演變目的: 用簡單的方法處理愈來愈複雜的View層

在最開始的時候，View層是很簡單的，甚至都沒有什麼畫面；而隨着信息時代的發展，它變得愈來愈複雜。如今，前端頁面會有不少複雜的交互邏輯和用戶體驗，若是還使用以前老的框架，對View層的操做就會難以維護，這就是前端框架要不斷演變的主要緣由。

2 框架的分類

框架分類：討論框架必定要結合應用場景和歷史背景

上世紀70年代，MVC誕生。最初是應用在GUI程序（圖形界面程序）上，而不是WEB程序上——對於這種MVC，咱們稱之爲經典MVC。後來，在WEB程序上的MVC都是經典MVC的變體；並且，WEB程序上後端MVC和前端MVC也會有些許區別。所以，不區分應用場景和歷史背景，就把經典MVC和WEB MVC混作一團是很是不負責任的。

另外，無論MVC，MVP，MVVM以及它們諸多的變體MVX，本質上都是三層的結構。

• Model管理數據和業務邏輯
• View渲染頁面
• X負責兩者之間的聯繫

回想咱們在文章第一部分就着重提到的，演變的最終目的就是爲了適應愈來愈複雜的View層，讓咱們一直記着這句話來看下面的內容。

3. MVC

第二部分已經提到過了，由於MVC變種衆多，不結合應用場景和歷史背景的討論都是耍流氓。

3.1 經典MVC

在上世紀70年代，由於沒有操做系統和消息循環，甚至鼠標的光標都須要咱們的UI系統來自行繪製，因此這時候用戶的輸入是由Controller來得到的[1]。Controller得到用戶的輸入以後，去調用相應的Model修改數據，同時修改View響應用戶的輸入。Model的數據修改以後，會通知相關的View。View監聽Model，當收到通知後，就修改樣式。

調用關係以下[2]：

3.2 WEB MVC

咱們能夠看到，WEB MVC和經典MVC本質上是同樣的，一樣都擁有了Controller去修改Model的調用關係。可是，它們之間有兩個區別：

1. 用戶輸入從Controller變爲了View：View承接了部分controller的功能，負責處理用戶輸入，可是沒必要了解下一步作什麼。它依賴於一個controller爲她作決定或處理用戶事件。
2. Controller的做用變小：在經典MVC中，「Controller是用戶和系統之間的連接」，可是在WEB MVC中，View既能夠委託Controller對Model進行修改，也能夠獨立處理用戶事件。在經典MVC中，Controller要作的事情多數是派發用戶輸入給不一樣的View，而這部分工做在WEB MVC中已經被系統作了。[3]所以，在WEB MVC中，Controller變得很薄，只剩下一些驗證輸入和路由的工做。

3.3 MVC的優缺點

優勢：

• 把業務邏輯和展現邏輯分離，模塊化程度高。且當應用邏輯須要變動的時候，不須要變動業務邏輯和展現邏輯，只須要Controller換成另一個Controller就好了。
• 觀察者模式能夠作到多視圖同時更新。

缺點：

• Controller測試困難。由於視圖同步操做是由View本身執行，而View只能在有UI的環境下運行。在沒有UI環境下對Controller進行單元測試的時候，應用邏輯正確性是沒法驗證的：Model更新的時候，沒法對View的更新操做進行斷言。
• View沒法組件化。View是強依賴特定的Model的，若是須要把這個View抽出來做爲一個另一個應用程序可複用的組件就困難了。由於不一樣程序的的Domain Model是不同的。[1]

4. MVVM

4.1 MVVM

感謝前端的前輩們，咱們並無在MVP階段多作逗留，而是大步進入了MVVM階段。其實MVP和MVVM的主要區別就是在因而否有雙向數據綁定。有興趣的能夠看《淺析 MVC, MVP 與 MVVM之間的異同》自行了解。

在3.2咱們實現了一個簡單的MVC，設想一下，如今頁面上不是隻有一個按鈕，而是有1000個按鈕，每一個按鈕還要操做不一樣的DOM對象，由於MVC是沒法組件化的，這時View的邏輯就會變得很是的複雜和難以維護。爲了解決這個問題，MVVM就應運而生了。

用戶與View交互，觸發用戶事件；View根據事件類型調用ViewModel中對應的響應邏輯；而後ViewModel中的響應邏輯在作完適當處理後，會去調用Model層的接口；接口的調用執行，致使Model層數據的變化，進而觸發相應的數據改變事件；事件又被ViewModel模塊監聽到；拿到新的Model數據，ViewModel中的展現邏輯會去修改ViewModel中的狀態數據；ViewModel中狀態數據的改變，最終引發View的狀態變換，完成了此次對用戶事件的響應。

4.1 MVVM優缺點

優勢：

• 組件化。View不依賴Model。這樣就可讓View從特定的業務場景中脫離出來，從而撰寫高度可複用的組件 。
• 提升可維護性。解決了MVP大量的手動View和Model同步的問題，提供雙向綁定機制。由於同步邏輯是交由Binder作的，View跟着Model同時變動，因此只須要保證Model的正確性，View就正確。大大減小了對View同步更新的測試。

缺點：

• 過於簡單的圖形界面不適用

5. 參考文獻

1. 《前端設計模式》
2. 《淺析 MVC, MVP 與 MVVM之間的異同》
3. 《界面之下，還原真實的MV*》
4. 《前端MVC變形記》
5. 《MVC wiki》
6. 《談談UI架構設計的演化》
7. 《MVC,MVP,MVVM的圖示》