資訊專欄INFORMATION COLUMN
摘要：所以我查了很多的材料，希望能從自己的角度上用通俗的語言闡述前端框架的演變。現在，前端頁面會有很多復雜的交互邏輯和用戶體驗，如果還使用之前老的框架，對層的操作就會難以維護，這就是前端框架要不斷演變的主要原因。
說實在的，我不覺得MVC，MVVM這些框架有什么難的，直到我想寫一篇文章去系統的闡述它們。我遇到了以下幾個問題，1.不同的文章說的南轅北轍 2.沒有一個清晰的大綱和框架分類。所以我查了很多的材料，希望能從自己的角度上用通俗的語言闡述前端框架的演變。1 演變的目的
演變目的: 用簡單的方法處理越來越復雜的View層
在最開始的時候，View層是很簡單的，甚至都沒有什么畫面；而隨著信息時代的發展，它變得越來越復雜?，F在，前端頁面會有很多復雜的交互邏輯和用戶體驗，如果還使用之前老的框架，對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的調用關系。但是，它們之間有兩個區別：
用戶輸入從Controller變為了View：View承接了部分controller的功能，負責處理用戶輸入，但是不必了解下一步做什么。它依賴于一個controller為她做決定或處理用戶事件。
Controller的作用變?。涸诮浀銶VC中，“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的狀態變換，完成了這次對用戶事件的響應。
優點：
組件化。View不依賴Model。這樣就可以讓View從特定的業務場景中脫離出來，從而撰寫高度可復用的組件 。
提高可維護性。解決了MVP大量的手動View和Model同步的問題，提供雙向綁定機制。因為同步邏輯是交由Binder做的，View跟著Model同時變更，所以只需要保證Model的正確性，View就正確。大大減少了對View同步更新的測試。
缺點：
過于簡單的圖形界面不適用
5. 參考文獻《前端設計模式》
《淺析 MVC, MVP 與 MVVM之間的異同》
《界面之下，還原真實的MV*》
《前端MVC變形記》
《MVC wiki》
《談談UI架構設計的演化》
《MVC,MVP,MVVM的圖示》
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/52443.html
摘要：所以我查了很多的材料，希望能從自己的角度上用通俗的語言闡述前端框架的演變?，F在，前端頁面會有很多復雜的交互邏輯和用戶體驗，如果還使用之前老的框架，對層的操作就會難以維護，這就是前端框架要不斷演變的主要原因。 說實在的，我不覺得MVC，MVVM這些框架有什么難的，直到我想寫一篇文章去系統的闡述它們。我遇到了以下幾個問題，1.不同的文章說的南轅北轍 2.沒有一個清晰的大綱和框架分類。所以我...
摘要：更詳細的內容下一章開篇深入聊聊前后分離講述關于我目前在寫從零構建前后分離項目系列，修正和補充以此為準不斷更新的項目實踐地址彩蛋提前預覽下一章傳送門 開篇 ： 縱觀WEB歷史演變 在校學習和幾年工作工作中不知不覺經歷了一半的 WEB 歷史演變、對近幾年的發展比較了解，結合經驗聊聊 WEB 發展歷史。 演變不易，但也是必然，因為為人始終要進步。 WEB 的發展史 一、開山鼻祖 - 石器時代...
摘要：更詳細的內容下一章開篇深入聊聊前后分離講述關于我目前在寫從零構建前后分離項目系列，修正和補充以此為準不斷更新的項目實踐地址彩蛋提前預覽下一章傳送門 開篇 ： 縱觀WEB歷史演變 在校學習和幾年工作工作中不知不覺經歷了一半的 WEB 歷史演變、對近幾年的發展比較了解，結合經驗聊聊 WEB 發展歷史。 演變不易，但也是必然，因為為人始終要進步。 WEB 的發展史 一、開山鼻祖 - 石器時代...
閱讀 25629·2021-09-29 09:41
閱讀 4787·2021-09-10 11:20
閱讀 1918·2021-09-09 09:32
閱讀 1881·2019-08-30 15:44
閱讀 3192·2019-08-29 17:13
閱讀 2809·2019-08-29 14:14
閱讀 2061·2019-08-29 14:11
閱讀 3221·2019-08-29 12:36
