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