關于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¹
如果你把10個軟體架構師放在一個房間里，讓他們討論模型-視圖-控制器模式是什么，你最侄訓得到12種不同的觀點，

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

MVVM 名詞解釋：

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

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

MVVM 的發展歷程

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，³

MVC到MVVM 的發展歷程

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

Java Web Model2
view負責顯示，Model負責提供資料，Controller負責邏輯的處理，其實作的流程大概是：⁴

(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框架的弊端就顯現出來⁴，這也是使用Servlet+JSP的弊端，前后端沒有解耦，Model與View沒有徹底解耦，

為了解決MVC框架中View和Model聯系緊密的問題，開發者研究開發了MVP模式，MVP即Model-View-Presenter，即把MVC中的Controller換成了Presenter，目的就是為了完全切斷View跟Model之間的聯系，在MVP模式中，View負責視圖的顯示,Model負責提供資料，Presenter則主要負責邏輯業務的處理，⁴ 有些SSM+JSP的開發方式也是基于這種，我之前的公司就這樣寫，前后端不分離使用的JSP，但是互動全是Ajax，傳遞的全是JSON，也沒有回傳ModelAndView，個人感覺這里其實是使用了MVP的模式，一直想不明白這樣寫的其他好處，是為了服務端渲染考慮嗎？那為啥不用模板引擎回傳ModelAndView，向小伙伴請教，
在這里插入圖片描述
在MVP框架中，View無法直接再與Model互動，View和Model之間的通信都是通過Presenter進行完成的，所有的互動都在Presenter內部發生，即由Presenter充當了View和Model的橋梁，做到View-Model之間通信的完全隔離，Presenter完全把Model和View進行分離，將主要的程式邏輯放在Presenter里實作，⁴

Presenter與View也是沒有直接相關聯的，而是通過已定義的介面進行互動，從而使得在變更View的時候可以保持Presenter的不變，即保證了Presenter的可重用性(介面的復用性)，同時也解決了MVC框架中的View和Model關聯緊密的問題，⁴

這樣之后，對于Web專案來講，前后端都是通過資料進行互動，那路由怎么處理，前端只能實作簡單一部分跳轉，涉及到復雜的需要通過Controller(Presenter)來處理的路由怎么處理，或者帶狀態的路由如何跳轉，即Controller無法控制使用那個View，

有個叫Rod Johnson帶領一幫人搞出的SpringMVC，不像桌面應用的MVC，這里的Model沒法給View 發通知，⁵也不像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上面，從而實作資料與模型的雙向系結，⁴

在MVVM框架中，View用于發送用戶的互動請求，之后將用戶請求轉交給ViewModel，ViewModel即可根據用戶請求操作Model資料更新，待Model資料更新完畢，便會通知ViewModel資料發生了變化，然后ViewModel就會即刻更新View資料，完成視圖的更新，從而完成用戶的請求，⁴
在這里插入圖片描述

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

首先，MVVM框架中的View完全可以獨立于Model發生變化和修改，徹底解耦，View發生變化時Model可以不變，同樣，當Model發生變化時View也可以不變化，并且一個ViewModel可以系結到多個不同的View上面，這就體現了MVVM框架的低耦合性，
其次，系結在一個ViewModel上面的多個View都可以使用ViewModel里面的視圖邏輯，完成了框架可重用性的特性，除此之外，MVVM框架還具有可獨立開發、可測驗等特性，把框架作用發揮到最大化，也因此成為了開發者們青睞的框架，，

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

Model 僅僅只是代表應用程式所需的資料資訊，它不關注任何行為；
View 是軟體中與用戶進行直接互動的部分，它需要回應 ViewModel 的事件并格式化資料，不負責控制應用的狀態；
ViewModel 用于封裝業務邏輯層，這點類似于 MVC 模式中的控制器，它控制View的很多顯示邏輯，它可以把資料模型的變化傳遞給視圖，也可以把視圖中資料的變化傳遞給資料模型，即在 Model 和View 之間建立了雙向系結，

Vue與MVVM

我第一次看到MVVM是因為Vue，相信好多小伙伴也是Vue認識MVVM架構模式，Vue官網中講到：雖然沒有完全遵循 MVVM 模型，但是 Vue 的設計也受到了它的啟發，因此在檔案中經常會使用 vm (ViewModel 的縮寫) 這個變數名表示組件實體
在這里插入圖片描述
通過雙向資料系結連接視圖層和資料，而實際的界面 UI 操作（DOM 操作）被封裝成對應的指令（Directives）和過濾器（Filters）

MVVM原理：⁷

實作資料系結的做法有大致如下幾種：

臟值檢查（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 中的運行原理，

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Two-way data-binding</title>
</head>
<body>
    <div id="app">
        <input type="text" v-model="text">
        {{ text }}
    </div>
    <script>
        function observe (obj, vm) {
            Object.keys(obj).forEach(function (key) {
                defineReactive(vm, key, obj[key]);
            });
        }
        function defineReactive (obj, key, val) {
            var dep = new Dep();
            Object.defineProperty(obj, key, {
                get: function () {
                    if (Dep.target) dep.addSub(Dep.target);
                    return val
                },
                set: function (newVal) {
                    if (newVal === val) return
                    val = newVal;
                    dep.notify();
                }
            });
        }
        function nodeToFragment (node, vm) {
            var flag = document.createDocumentFragment();
            var child;
            while (child = node.firstChild) {
                compile(child, vm);
                flag.appendChild(child);
            }
            return flag;
        }
        function compile (node, vm) {
            var reg = /\{\{(.*)\}\}/;
            // 節點型別為元素
            if (node.nodeType === 1) {
                var attr = node.attributes;
                // 決議屬性
                for (var i = 0; i < attr.length; i++) {
                    if (attr[i].nodeName == 'v-model') {
                        var name = attr[i].nodeValue; // 獲取v-model系結的屬性名
                        node.addEventListener('input', function (e) {
                            // 給相應的data屬性賦值，進而觸發該屬性的set方法
                            vm[name] = e.target.value;
                        });
                        node.value = vm[name]; // 將data的值賦給該node
                        node.removeAttribute('v-model');
                    }
                }
                new Watcher(vm, node, name, 'input');
            }
            // 節點型別為text
            if (node.nodeType === 3) {
                if (reg.test(node.nodeValue)) {
                    var name = RegExp.$1; // 獲取匹配到的字串
                    name = name.trim();
                    new Watcher(vm, node, name, 'text');
                }
            }
        }
    
        function Watcher (vm, node, name, nodeType) {
        //  this為watcher函式
            Dep.target = this;
        //  console.log(this);
            this.name = name;
            this.node = node;
            this.vm = vm;
            this.nodeType = nodeType;
            this.update();
            Dep.target = null;
        }
        Watcher.prototype = {
            update: function () {
                this.get();
                if (this.nodeType == 'text') {
                    this.node.nodeValue = this.value;
                }
                if (this.nodeType == 'input') {
                    this.node.value = this.value;
                }
            },
            // 獲取daa中的屬性值
            get: function () {
                this.value = this.vm[this.name]; // 觸發相應屬性的get
            }
        }
        function Dep () {
            this.subs = []
        }
        Dep.prototype = {
            addSub: function(sub) {
                this.subs.push(sub);
            },
            notify: function() {
                this.subs.forEach(function(sub) {
                    sub.update();
                });
            }
        };
        function Vue (options) {
            this.data = options.data;
            var data = this.data;
            observe(data, this);
            var id = options.el;
            var dom = nodeToFragment(document.getElementById(id), this);
            // 編譯完成后，將dom回傳到app中
            document.getElementById(id).appendChild(dom);
        }
        var vm = new Vue({
            el: 'app',
            data: {
                text: 'hello world'
            }
        });
    </script>
</body>
</html>

我的理解

架構意義角度(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，

參考文獻資料

淺析 web 前端 MVVM[db/ol].https://zhuanlan.zhihu.com/p/54355504 ??
百度百科[db/ol].https://baike.baidu.com/item/MVVM/96310?fr=aladdin ??
上海科創資料資源中心[db/ol].http://www.sstir.cn/search/list?keyword=MVVM ?? ??
程桂花.MVVM前后端資料互動中安全機制的研究與實作[D].浙江理工大學碩士學位設計,2017:6-7 ?? ?? ?? ?? ?? ?? ?? ?? ??
你真的理解了MVC, MVP, MVVM嗎？[db/ol].https://blog.csdn.net/wdr2003/article/details/79811767 ??
易劍波.基于 MVVM 模式的 WEB 前端框架的研究[D].計算機工程應用技術,2016.19:76] ??
Vue MVVM理解及原理實作[db/ol].https://juejin.cn/post/6844903929298288647 ?? ??

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/287597.html

標籤：其他

上一篇：從零開始學架構-day05

下一篇：(七) Spring學習總結

關于MVVM和MVC的一些總結