關于 MVVM和MVC的這些，你知道嗎？（關于我轉生變成史萊姆這檔事）

我的需求

：

晚上練完車之后,之前參考我畢設的一個小伙伴要答辯，問了我一個問題，結果問的一下不知道怎么回答…以下是我回答他問題的答案：所以在回答完他之后，趕快整理一波…

我需要解決的問題

：

MVVM到底是個什么東東，和前后端有沒有關系，它和MVC區別是啥，有啥優勢。

我是這樣做的

：

百度尋找，找了一些關于MVVM論文，博客，梳理出自己的答案。

嗯，資源比較零散，準確性有待考量，

所以不對的地方請小伙伴指出來

。

愛自己，是終生浪漫的開始 ------王爾德

對于MVC想來小伙伴是不陌生的，但是網上的資源各抒己見…我也整的暈頭轉向的，可能有前(后)端,有胖(瘦)客戶端框架應用，具體還有細微的差異。

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 Smith[^3]

如果你把10個軟件架構師放在一個房間里，讓他們討論模型-視圖-控制器模式是什么，你最終會得到12種不同的觀點。

我們這里討論的MVC和MVVM是以BS架構為基礎的java Web中的應用，因為博主只接觸了這方面的，關于網上提到的IOS和一些客戶端框架，沒有接觸過。本博客也不涉及。所以如果聽都沒聽過java Web的,或者沒了解過 Web框架的小伙伴個人感覺這篇博客不太適合，不太建議繼續讀下去。

我們先看看MVVM吧！嘻嘻 ^ _ ^

MVVM是Model-View-ViewModel的簡寫。它本質上就是MVC的改進版。MVVM 就是將其中的View的狀態和行為抽象化，讓我們將視圖 UI和業務邏輯分開。當然這些事ViewModel已經幫我們做了，它可以取出 Model 的數據同時幫忙處理View中由于需要展示內容而涉及的業務邏輯。MVVM（Model-View-ViewModel）框架的由來便是MVP（Model-View-Presenter）模式與WPF結合的應用方式時發展演變過來的一種新型架構框架。它立足于原有MVP框架并且把WPF的新特性糅合進去，以應對客戶日益復雜的需求變化。^1

MVVMupright=1.5 MVVM（Model–view–viewmodel）是一種軟件架構模式。 MVVM有助于將圖形用戶界面的開發與business logic(業務邏輯)或后端邏輯（數據模型）的開發分離開來，這是通過置標語言或GUI代碼實現的。MVVM的視圖模型是一個值轉換器， 這意味著視圖模型負責從模型中暴露（轉換）數據對象，以便輕松管理和呈現對象。在這方面，視圖模型比視圖做得更多，并且處理大部分視圖的顯示邏輯。 視圖模型可以實現中介者模式，組織對視圖所支持的用例集(Model)的后端邏輯的訪問。 ^2

MVVM是馬丁·福勒的PM（Presentation Model）設計模式的變體。MVVM以相同的方式抽象出視圖的狀態和行為， 但PM以不依賴于特定用戶界面平臺的方式抽象出視圖（建立了視圖模型）。 MVVM和PM都來自MVC模式。 MVVM由微軟架構師Ken Cooper和Ted Peters開發，通過利用WPF（微軟.NET圖形系統）和Silverlight（WPF的互聯網應用衍生品）的特性來簡化用戶界面的事件驅動程式設計。 微軟的WPF和Silverlight架構師之一John Gossman于2005年在他的博客上發表了MVVM。 MVVM也被稱為model-view-binder，特別是在不涉及.NET平臺的實現中。ZK（Java寫的一個Web應用框架）和KnockoutJS（一個JavaScript庫）使用model-view-binder。^2

二十世紀八十年代施樂帕克實驗室提出了MVC的概念，MVC的全稱即Model-View-Controller，是模型(model)一視圖(view)一控制器(controller)的縮寫“…，它是一種客戶端軟件開發框架[^4]，個人認為，其實最初的Java Web來講，Model2 即Servlet+JSP也是用的這個結構，所以說Model2(MVC)它相對已Model1(Javabean+JSP)來講，已經實現了View和Model的部分解耦，但是不徹底，如圖

view負責顯示，Model負責提供數據，Controller負責邏輯的處理，其實現的流程大概是：[^4]

(1)當用戶需要發送請求時，首先是在View發送請求，由View將指令傳送到Controller里。

(2)Controller接收到指令之后，先完成所需要的業務邏輯，然后要求Model根據業務邏輯改變狀態；

(3)Model將新的數據發送給View，View則根據新的數據更新視圖，從而用戶的請求得到反饋。

在MVC框架中，View是可以直接訪問Model的(JSP里直接使用JavaBean)，這樣不可避免的使View里面也需要包括一些業務邏輯，同時還需要Model保持不變，而Model又對應著多個不同的顯示(View)，所以總體說來就是，在MVC模型里面，Model不依賴View，但是View是依賴于Model的。這樣就導致更改View比較困難，且業務無法重用。從而MVC框架的弊端就顯現出來[^4]，這也是使用Servlet+JSP的弊端。前后端沒有解耦，Model與View沒有徹底解耦。

為了解決MVC框架中View和Model聯系緊密的問題，開發者研究開發了MVP模式，

MVP即Model-View-Presenter，即把MVC中的Controller換成了Presenter，目的就是為了完全切斷View跟Model之間的聯系，在MVP模式中，View負責視圖的顯示,Model負責提供數據，Presenter則主要負責邏輯業務的處理。[^4]

有些SSM+JSP的開發方式也是基于這種，我之前的公司就這樣寫，前后端不分離使用的JSP，但是交互全是Ajax，傳遞的全是JSON，也沒有返回ModelAndView，個人感覺這里其實是使用了MVP的模式。以前后端不分離的方式丟棄模板引擎的服務端渲染，追求前后端分離中徹底解耦了View和Model。看上去怪怪的，其實有時候項目開發更多的是和業務、體量、成本、效益等有關系，綜合考慮，選最合適，不一定要按照常規的構建方式考慮，比如正常思考可能不分離是為了服務端渲染，首屏快載，SEO等，分離是為了降低服務器壓力，接口復用，前后端工作職責解耦.

對于SSM+模板引擎的開發方式

如何是返回Modelandview的話，那缺點就是后端路由，前后端沒有徹底解耦，優點就是服務端渲染，返回的是整個構建好的頁面.

如果返回JSON的話，那優點就是前后端徹底解耦，接口復用，但是沒有利用模板引擎的服務端渲染。

如果體量很大，那前后端是兩個人寫，那使用Modelandview的方式就很麻煩，需要接口協調，而且工作職責不清晰。會浪費好多時間。JSON就方便很多。

如果體量不是他大，前端的東西也不是特別多，考慮成本問題，前后端一個人寫，那Modelandview就很合適，節省了接口協調，對接等時間成本問題。

在MVP框架中，View無法直接再與Model交互，View和Model之間的通信都是通過Presenter進行完成的，所有的交互都在Presenter內部發生，即由Presenter充當了View和Model的橋梁，做到View-Model之間通信的完全隔離。Presenter完全把Model和View進行分離，將主要的程序邏輯放在Presenter里實現。[^4]

Presenter與View也是沒有直接相關聯的，而是通過已定義的接口進行交互

，從而使得在變更View的時候可以保持Presenter的不變，即保證了Presenter的可重用性(接口的復用性)，同時也解決了MVC框架中的View和Model關聯緊密的問題。[^4]

這樣之后，對于Web項目來講，前后端都是通過數據進行交互，那路由怎么處理，前端只能實現簡單一部分跳轉，涉及到復雜的需要通過Controller(Presenter)來處理的路由怎么處理，或者帶狀態的路由如何跳轉，即Controller無法控制使用那個View。個人感覺，Web系統來講這個時候完全的前后端分離可能不是適合所有項目，而且分離之后留給前端要解決的問題可能也不是能很好的解決。所以這個時候…

有個叫Rod Johnson帶領一幫人搞出的SpringMVC，不像桌面應用的MVC， 這里的Model沒法給View 發通知。[^5]也不像MVP, 這里的Controller可以控制View來實現路由。即前后后端沒有分離，但是將原來的View的構建解耦了。由模板和數據構成：

public class MyGlobalException { @ExceptionHandler(MaxUploadSizeExceededException.class) public ModelAndView customException(MaxUploadSizeExceededException e) { ModelAndView mv = new ModelAndView("javaboy"); mv.addObject("error", e.getMessage()); return mv; } }

即降低了View和Model耦合，同時又實現了后端路由。

對于大型項目而言，前端的東西原來越多，造成服務端的壓力越來越大，而且由于MVP的出現，逐漸向前后端分離靠攏，分離之后，View分擔服務端的壓力，或者說是瀏覽器分擔了服務器壓力，包括頁面渲染，路由等問題，這時侯MVVM出現了…（

這里是自己猜的，沒找到相關資料

）

MVVM框架便是前后端分離框架發展史上的一次思想的完全變革。它是將數據模型雙向綁定的思想作為變革的核心，即View的變動，自動反映在ViewModel上面，而ViewModel的變動也會隨即反映在View上面，從而實現數據與模型的雙向綁定。[^4]

在MVVM框架中，View用于發送用戶的交互請求，之后將用戶請求轉交給ViewModel，ViewModel即可根據用戶請求操作Model數據更新，待Model數據更新完畢，便會通知ViewModel數據發生了變化，然后ViewModel就會即刻更新View數據，完成視圖的更新，從而完成用戶的請求。[^4]

雖然MVVM框架和之前的MVC、MVP模式的目的相同，即完成視圖(View)和模型(Model)的分離，但它卻有著明顯的優勢。[^4]

首先，MVVM框架中的View完全可以獨立于Model發生變化和修改，徹底解耦，View發生變化時Model可以不變，同樣，當Model發生變化時View也可以不變化，并且一個ViewModel可以綁定到多個不同的View上面，這就體現了MVVM框架的低耦合性。

其次，綁定在一個ViewModel上面的多個View都可以使用ViewModel里面的視圖邏輯，完成了框架可重用性的特性。除此之外，MVVM框架還具有可獨立開發、可測試等特性，把框架作用發揮到最大化，也因此成為了開發者們青睞的框架。。

對于MVVM這種模式主要用于構建基于事件驅動的 UI 平臺，對于前端開發領域中數據與界面相混合的情況特別適用[^6]，其中

Model 僅僅只是代表應用程序所需的數據信息，它不關注任何行為；

View 是軟件中與用戶進行直接交互的部分，它需要響應 ViewModel 的事件并格式化數據，不負責控制應用的狀態；

ViewModel 用于封裝業務邏輯層，這點類似于 MVC 模式中的控制器，它控制View的很多顯示邏輯，它可以把數據模型的變化傳遞給視圖，也可以把視圖中數據的變化傳遞給數據模型，即在 Model 和View 之間建立了雙向綁定。

我第一次看到MVVM是因為Vue，相信好多小伙伴也是Vue認識MVVM架構模式。Vue官網中講到：

雖然沒有完全遵循 MVVM 模型，但是 Vue 的設計也受到了它的啟發。因此在文檔中經常會使用 vm (ViewModel 的縮寫) 這個變量名表示組件實例

通過雙向數據綁定連接視圖層和數據，而實際的界面 UI 操作（DOM 操作）被封裝成對應的指令（Directives）和過濾器（Filters）

實現數據綁定的做法有大致如下幾種：

臟值檢查（angular.js）

: angular.js 是通過臟值檢測的方式比對數據是否有變更，來決定是否更新視圖，最簡單的方式就是通過 setInterval() 定時輪詢檢測數據變動，angular只有在指定的事件觸發時進入臟值檢測.

DOM事件，譬如用戶輸入文本，點擊按鈕等。( ng-click)

XHR響應事件 ($http )

瀏覽器Location變更事件 ( $location )

Timer事件( $timeout , $interval )

執行 $digest() 或 $apply()

數據劫持（vue.js）

:數據劫持，指的是在訪問或者修改對象的某個屬性時，通過一段代碼攔截這個行為，進行額外的操作或者修改返回結果。簡單地說，就是當我們觸發函數的時候 動一些手腳做點我們自己想做的事情，也就是所謂的 "劫持"操作

在Vue中其實就是通過Object.defineProperty來劫持對象屬性的setter和getter操作，并“種下”一個-，當數據發生變化的時候發出通知:Object.defineProperty(obj,prop,descriptor)

參數：

obj:目標對象

prop:需要定義的屬性或方法的名稱

descriptor:目標屬性所擁有的特性

可供定義的特性列表：

value:屬性的值

writable:如果為false，屬性的值就不能被重寫。

get: 一旦目標屬性被訪問就會調回此方法，并將此方法的運算結果返回用戶。

set:一旦目標屬性被賦值，就會調回此方法。

configurable:如果為false，則任何嘗試刪除目標屬性或修改屬性性以下特性（writable, configurable, enumerable）的行為將被無效化。

enumerable:是否能在for…in循環中遍歷出來或在Object.keys中列舉出來。

Proxy數據代理:Proxy 可以被認為是Object.defineProperty() 的升級版。外界對某個對象的訪問，都必須經過這層攔截。因此它是針對 整個對象，而不是 對象的某個屬性。

var data = {name:'test'} Object.keys(data).forEach(function(key){ Object.defineProperty(data,key,{ enumerable:true, configurable:true, get:function(){ console.log('get'); }, set:function(newValue){ console.log('監聽到數據發生了變化'); document.getElementById(‘myText’).value=newValue; } }) }); document.getElementById(‘myText’).addEventListener(‘keyup’,function(e){ data.name=e.target.value; // 監聽 View 的變化，同步更新 Model }); data.name //控制臺會打印出 “get” data.name = 'hxx' //控制臺會打印出 "監聽到數據發生了變化"

var arr = [1,2,3] var handle = { //target目標對象 key屬性名 receiver實際接受的對象 get(target,key,receiver) { console.log(`get ${key}`) // Reflect相當于映射到目標對象上 return Reflect.get(target,key,receiver) }, set(target,key,value,receiver) { console.log(`set ${key}`) return Reflect.set(target,key,value,receiver) } } //arr要攔截的對象，handle定義攔截行為 var proxy = new Proxy(arr,handle) proxy.push(4) //可以翻到控制臺測試一下會打印出什么

發布者-訂閱者模式（backbone.js）

:

上述介紹了簡單的一對一雙向綁定的實現，即一個數據模型只與一個視圖進行綁定。當多個View與一個 Model進行綁定時，每次更新 Model時需要在Model 的set訪問器屬性中更新多個 View，這樣硬編碼的方式不利于后期的維護。為了解決硬編碼帶來的耦合性過強的問題，在在實際實現中，需要使用到設計模式中的發布 - 訂閱模式。

發布 - 訂閱模式（又稱觀察者模式）是一種常用的設計模式，該模式包含發布者和訂閱者兩種角色。可以讓多個訂閱者訂閱同一個發布者發布的主題，當發布者的主題發生變化時，對外發送一個通知，所有訂閱了該主題的訂閱者都會接收到更新的消息。因此，觀察者模式定義的是一種一對多的關系。發布 - 訂閱模式非常適合于 MVVM 雙向綁定中多個視圖綁定到同一個數據模型的情形。

要實現mvvm的雙向綁定，就必須要實現以下幾點：

實現一個指令解析器Compile，對每個元素節點的指令進行掃描和解析，根據指令模板替換數據，以及綁定相應的更新函數

實現一個數據-Observer，能夠對數據對象的所有屬性進行監聽，如有變動可拿到最新值并通知訂閱者（Dep）

實現一個Watcher，Watcher是訂閱 - 發布模式中訂閱者的實現，作為連接Observer和Compile的橋梁，能夠訂閱并收到每個屬性變動的通知，執行指令綁定的相應回函數 （發布），從而更新視圖

MVVM入口函數，整合以上三者

當新建一個Vue 對象時，框架進入初始化階段。Vue 在初始化階段主要執行兩個操作：

第一個是遍歷系統中數據的所有屬性，來對各個屬性的變化添加監聽；

第二個操作是利用指令編譯器 Compile對視圖中綁定的指令進行掃描進行視圖的初始化，然后訂閱 Watcher 來更新視圖，此時 Watcher 會將自己添加到消息訂閱器Dep中。至此，Vue的初始化過程結束。

在系統運行過程中，一旦系統中的數據模型發生了變化，觀察者 Observer的 setter 訪問器屬性就會被觸發，此時消息訂閱中心 Dep 會遍歷它所維護的所有訂閱者，對于每一個訂閱了該數據的對象，向它發出一個更新通知，訂閱者收到通知后就會對視圖進行相應的更新。以上過程不斷往復循環，這就是 MVVM 模式在 Vue.js 中的運行原理。

架構意義角度(Web端的角度)

：MVC和MVVM在本質上都是為了實現View和Model的解耦，MVC是通過Controller實現了View和Model的解耦，一般用與客戶端，或者Web端的整個架構過程；而MVVM是在MVC發展到MVP后(為了徹底解決View和Model的耦合問題)，在提出前后端分離的基礎上(考慮Coltroller的復用性，接口復用性)，對View層進行了增強(Vue.js)，或者說細化了View層的表現手法，提出了通過ViewModel對視圖層的View和Model解耦。

個人感覺MVVM和MVP的整體架構是有相似的地方的，不同的是面對的問題域不同，MVP是Web架構整體的解決方案，MVVM主要用于構建基于事件驅動的 UI 平臺(界面)，適用于前端開發領域中數據與界面相混合的情況，所以它只專注于視圖層，抽象出視圖的狀態和行為，實現了用戶界面的UI(View)和數據(Model)的解耦。這個View和Model雖然和MVC中描述的一樣，但是不相同的，可以理解為MVC中View中包含了MVVM的架構方式。

一般前后端分離的Web開發中會結合MVC和MVVM兩種架構模式。使用MVC構建整體的Web架構，使用MVVM解決View層DOM和data的耦合問題。

設計模式角度考慮

：MVC是基于觀察者設計模式的，Model作為一個主題，View作為觀察者，當一個Model變化時，會通知更新一個或多個依賴的View，反之；

MVVM可以看做是基于中介者設計模式和觀察者設計模式，View和Model通過ViewModel這個中介者對象進行交互，解耦了View和Model的同時實現數據雙向綁定。

同時ViewModel 作為一個主題對象，View和Model為兩個觀察者(或者可以理解為View為主題時，Model為觀察者，反之。這里的Model View起到一個注冊，通知的作用，對于觀察者模式的定義，ModelView是主題的行為，但實際變化的是View或者Model，

個人覺得兩種理解都沒問題，理解不對的請小伙伴指出來

)，當Model變化時，ViewModel由數據綁定通知并更新與之相關的多個View，反之，當View變化時，ViewModel由DOM監聽通知更新相關的多個Model。

[^3]:淺析 web 前端 MVVM[db/ol].https://zhuanlan.zhihu.com/p/54355504

[^4]:程桂花.MVVM前后端數據交互中安全機制的研究與實現[D].浙江理工大學碩士學位設計,2017:6-7

[^5]:你真的理解了MVC, MVP, MVVM嗎？[db/ol].https://blog.csdn.net/wdr2003/article/details/79811767

[^6]:易劍波.基于 MVVM 模式的 WEB 前端框架的研究[D].計算機工程應用技術,2016.19:76]

[^7]:Vue MVVM理解及原理實現[db/ol].https://juejin.cn/post/6844903929298288647

Java

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。