摘要:它由微軟架構(gòu)師和開發(fā),通過利用微軟圖形系統(tǒng)和的互聯(lián)網(wǎng)應(yīng)用派生品的特性來簡化用戶界面的事件驅(qū)動程序設(shè)計。微軟的和架構(gòu)師之一于年在他的博客上發(fā)表了。更改時會得到提醒這個情況是一個單向流。
前言
記得四個月前有一次面試,面試官問我 MVVM 是什么,MVVM 的本質(zhì)是什么。我大腦一片混亂,那時我對 MVVM 的認(rèn)知就只是“雙向綁定“和“Vue”,以這個關(guān)鍵字簡單回答了幾句,我反問 MVVM 的本質(zhì)是什么,對方就重復(fù)一次雙向綁定。我怎么覺得對方也沒懂就隨便這么一問呢...
其實面試完我就急著探求 MVVM 的真諦,查了資料,做了筆記,以下是我四個月前的理解:
ViewModel 和 View 是互相綁定的,我們不直對界面進(jìn)行操作,只需要修改數(shù)據(jù)。而和 MVC 的區(qū)別是:MVC 的 C,接收了數(shù)據(jù),需要手動通過 js 修改 dom,這包含了對 V 的操作而無論是 vue 還是 react,都不需要對 dom 進(jìn)行操作,view 和 viewmodel 的聯(lián)系顯然比 mvc 里 vc 的聯(lián)系緊密多了,這就是我們常說的雙向綁定。我覺得是不是沒有必要把 MV* 搞得這么清楚?只要知道 MVVM 的本質(zhì)是雙向數(shù)據(jù)綁定就好了?
四個月前的我投降了,為了應(yīng)付面試我依然只記得雙向綁定,而且 MVC 和 MVVM 的概念依然不清晰,本質(zhì)的區(qū)別還是沒搞懂。
不過不清晰真的很正常。
因為網(wǎng)上關(guān)于 mvvm 和其他 mv 結(jié)構(gòu)的文章不少,按道理應(yīng)該不難理解,但是很多文章對 mv 的描述都不一致,這就導(dǎo)致很多本來就懵逼的小白更加混亂(沒錯就是我)。
If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. --Josh SmithMVVM 基本信息
MVVM 是一種架構(gòu)模式,也被稱為 model-view-binder。它由微軟架構(gòu)師 Ken Cooper 和 Ted Peters 開發(fā),通過利用 WPF(微軟 .NET 圖形系統(tǒng))和 Silverlight(WPF 的互聯(lián)網(wǎng)應(yīng)用派生品)的特性來簡化用戶界面的事件驅(qū)動程序設(shè)計。微軟的 WPF 和 Silverlight 架構(gòu)師之一John Gossman 于 2005 年在他的博客上發(fā)表了 MVVM。
MVVM 結(jié)構(gòu)初見MVVM 與其他兩種架構(gòu)的對比:
MVVM:VM 在 UI 層之下。VM 為 view 暴露數(shù)據(jù)和方法,VM 推送數(shù)據(jù)到在它之下的 model。
MVC:view 層在結(jié)構(gòu)頂層,controller 在 view 之下。model 在 controller 之下。view 指向 controller,controller 指向 model。model 更改時 view 會得到提醒(這個情況是一個單向流)。
MVP:controller 替換為 presenter。presenter 與 view 平起平坐。presenter 監(jiān)聽 view 和 model 的事件,作為中間人在他們之間調(diào)解兩邊的事件,輔助兩邊交流。
MVVM 對于 MVC 來說更容易理解,因為 MVC 經(jīng)過長久的實踐,產(chǎn)生了很多框架,這些框架的適用領(lǐng)域也各有不同:有后端渲染工程、原生應(yīng)用工程、前后端分離后的前端工程等,在實現(xiàn) MVC 模式時理所當(dāng)然地會有一定區(qū)別,這就導(dǎo)致了 MVC 的多樣性。所以對于不同的情況,對 MVC 的理解不是完全一樣的。同樣的情況 MVVM 也有,作為一個較新的模式,實現(xiàn)比 MVC 少。此文介紹的 MVVM 模式主要以 Vue 為中心理解。
MVVM 與 MVC 的對比認(rèn)真看過 Vue 文檔大概都能注意到,Vue 實例的變量名是 vm,文檔中還很嚴(yán)謹(jǐn)?shù)匮a充了一句 “雖然沒有完全遵循 MVVM 模型,但是 Vue 的設(shè)計也受到了它的啟發(fā)”。
按照上面不同的工程師眼里有不同的 MVC 結(jié)構(gòu)的引言,Vue 雖然“沒有完全遵循 MVVM 模型”,但是我覺得這就是一種 Vue 特化的 MVVM。
Vue 的 MVVMView:單文件里 標(biāo)簽的內(nèi)容,展現(xiàn)給用戶的內(nèi)容,與 ViewModel 雙向綁定,可以在其中插入 ViewModel 提供的數(shù)據(jù)。
ViewModel:Vue 實例整個都是 ViewModel,與 View 雙向綁定,用戶在 View 修改數(shù)據(jù)或發(fā)出 ajax 等指令時, ViewModel 會及時相應(yīng),接著向下修改 Model——至此可以看出 Model 和 View 是沒有直接關(guān)系的。
Model:這一層或者有歧義。為了更好理解 Model 需要引入 Vuex,在有 Vuex 的情況下,Vuex 提供的數(shù)據(jù)就是 Model,這符合后端架構(gòu)中 Model 包含業(yè)務(wù)邏輯的情況。但是在無 Vuex 的情況下,Model 應(yīng)該就是 Vue 實例的 data 屬性,也就是 JavaScript 數(shù)據(jù)對象本身。
前端 MVC與之對比,MVC 的情況:
View:一樣是展現(xiàn)給用戶的部分,整個或部分 HTML 頁面。
Model:JavaScript 的變量數(shù)據(jù)(可以包含 ajax 獲取數(shù)據(jù)的邏輯,或是一個數(shù)據(jù)管理機制),但是在這里要額外地添加提醒 View 更新的機制。幾個月前我還迷糊為什么 MVC 也有觀察者模式,MVC 的觀察者是 View,在 Model 注冊為觀察者就能在 Model 更新時更新。
Controller:用戶操作邏輯放置點,輸入是用戶的操作,輸出是對 Model 的修改。
那么問題來了:MVC 和 MVVM 都用了觀察者模式,兩者有何不同?
看圖說話:
在理解 MVVM 和 MVC 的區(qū)別時我糾結(jié)了很久,基于 Vue 來說,感覺非常像 MVC:頁面訂閱數(shù)據(jù);數(shù)據(jù)更新時頁面更新,但是看了這幅圖后豁然開朗。
圖中對比的是 MVC 和 MVP,但是 MVP 和 MVVM 的區(qū)別基本就是 MVVM 把三者間的操作自動綁定了,不用開發(fā)者操心 V 和 P 之間的相互操作。
MVC 是由 M 通知 V,但 MVVM 是 M 通知 VM(M 和 V 沒有直接關(guān)系)。
拓展:React 只是 MVC 的 V?至今還廣泛流傳這這么一句話:React不是一個MVC框架,而是一個用于構(gòu)建組件化UI的庫,是一個前端界面開發(fā)工具。
這不是錯的,但肯定是過時的。在 React 剛面世的時候,開發(fā)團(tuán)隊強調(diào)了這種新型的界面便攜方法(Jsx 使用函數(shù)生成界面),強調(diào) Virtual DOM 和 diff 算法,而后來,官網(wǎng)已經(jīng)把相關(guān)描述修改了。
理解、交流進(jìn)步不能缺少交流,如果大家對三種架構(gòu)模式的區(qū)別有不同見解,請一定要在評論區(qū)留言。文中若出現(xiàn)錯誤觀點也請?zhí)嵝?,謝謝熱愛編程的大家。
參考文獻(xiàn)
https://zh.wikipedia.org/wiki...
https://russelleast.wordpress...
https://medium.com/javascript...
https://web.archive.org/web/20150219153055/http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.hztianpu.com/yun/100816.html
摘要:的模式之間不同主要是與的數(shù)據(jù)傳遞的流程不同。所以無論是復(fù)雜化簡單化還是修改流程,基本都是因為技術(shù)棧變化了對應(yīng)做的調(diào)整。實例實際項目往往采用更靈活的方式,以為例。用戶可以向發(fā)送指令事件,再由直接要求改變狀態(tài)。與不發(fā)生聯(lián)系,都通過傳遞。 概述 M -V- X 本質(zhì)都是一樣的 重點還是在于M-V 的橋梁要靠 X來牽線。 X的模式之間不同 主要是 M與V 的數(shù)據(jù)傳遞的流程不同。數(shù)據(jù)傳遞的流程不...
摘要:所以我查了很多的材料,希望能從自己的角度上用通俗的語言闡述前端框架的演變?,F(xiàn)在,前端頁面會有很多復(fù)雜的交互邏輯和用戶體驗,如果還使用之前老的框架,對層的操作就會難以維護(hù),這就是前端框架要不斷演變的主要原因。 說實在的,我不覺得MVC,MVVM這些框架有什么難的,直到我想寫一篇文章去系統(tǒng)的闡述它們。我遇到了以下幾個問題,1.不同的文章說的南轅北轍 2.沒有一個清晰的大綱和框架分類。所以我...
摘要:所以我查了很多的材料,希望能從自己的角度上用通俗的語言闡述前端框架的演變?,F(xiàn)在,前端頁面會有很多復(fù)雜的交互邏輯和用戶體驗,如果還使用之前老的框架,對層的操作就會難以維護(hù),這就是前端框架要不斷演變的主要原因。 說實在的,我不覺得MVC,MVVM這些框架有什么難的,直到我想寫一篇文章去系統(tǒng)的闡述它們。我遇到了以下幾個問題,1.不同的文章說的南轅北轍 2.沒有一個清晰的大綱和框架分類。所以我...
摘要:先來看一張系統(tǒng)前后端架構(gòu)模型圖。一種接口的約定本文用于定義一種統(tǒng)一的接口設(shè)計方案,希望具有參考價值。,和都是常見的軟件架構(gòu)設(shè)計模式,它通過分離關(guān)注點來改進(jìn)代碼的組織方式。 如何無痛降低 if else 面條代碼復(fù)雜度 相信不少同學(xué)在維護(hù)老項目時,都遇到過在深深的 if else 之間糾纏的業(yè)務(wù)邏輯。面對這樣的一團(tuán)亂麻,簡單粗暴地繼續(xù)增量修改常常只會讓復(fù)雜度越來越高,可讀性越來越差,有沒...
閱讀 864·2023-04-25 15:13
閱讀 1479·2021-11-22 12:03
閱讀 880·2021-11-19 09:40
閱讀 1983·2021-11-17 09:38
閱讀 1800·2021-11-08 13:18
閱讀 703·2021-09-02 15:15
閱讀 1813·2019-08-30 15:54
閱讀 2791·2019-08-30 11:12