MVC，MVP 和 MVVM 模式如何選擇？

愛編碼的coder發表於2019-01-19

前言

做客戶端開發、前端開發對MVC、MVP、MVVM這些名詞不瞭解也應該大致聽過，都是為了解決圖形介面應用程式複雜性管理問題而產生的應用架構模式。

網上很多文章關於這方面的討論比較雜亂，各種MV模式之間的區別分不清，甚至有些描述都是錯誤的。本文追根溯源，從最經典的Smalltalk-80 MVC模式開始逐步還原圖形介面之下最真實的MV模式。

GUI程式所面臨的問題

圖形介面的應用程式提供給使用者視覺化的操作介面，這個介面提供給資料和資訊。使用者輸入行為（鍵盤，滑鼠等）會執行一些業務邏輯，可能會導致對應用程式資料的變更，資料的變更自然需要使用者介面的同步變更以提供最準確的資訊。例如使用者對一個電子表格重新排序的操作，應用程式需要響應使用者操作，對資料進行排序，然後需要同步到介面上。

在開發應用程式的時候，以求更好的管理應用程式的複雜性，基於職責分離（Speration of Duties）的思想都會對應用程式進行分層。在開發圖形介面應用程式的時候，會把管理使用者介面的層次稱為View，應用程式的資料為Model（注意這裡的Model指的是Domain Model，這個應用程式對需要解決的問題的資料抽象，不包含應用的狀態，可以簡單理解為物件）。Model層對應用程式的業務邏輯無知，只儲存資料結構和提供資料操作的介面

有了View和Model的分層，那麼就有了兩個問題：

1、響應使用者操作的業務邏輯（例如排序）的管理。

2、View如何同步Model的變更。

帶著這兩個問題開始探索MV模式，會發現這些模式之間的差異可以歸納為對這兩個問題處理的方式的不同。而幾乎所有的MV模式都是經典的Smalltalk-80 MVC的修改版。

Smalltalk-80 MVC

歷史背景

早在上個世紀70年代，美國的施樂公司（Xerox）的工程師研發了Smalltalk程式語言，並且開始用它編寫圖形介面的應用程式。而在Smalltalk-80這個版本的時候，一位叫Trygve Reenskaug的工程師設計了MVC圖形應用程式的架構模式，極大地降低了圖形應用程式的管理難度。而在四人�眾（GoF）的設計模式當中並沒有把MVC當做是設計模式，而僅僅是把它看成解決問題的一些類的集合。Smalltalk-80 MVC和GoF描述的MVC是最經典的MVC模式。

MVC的依賴關係

MVC除了把應用程式分成View、Model層，還額外的加了一個Controller層，它的職責就是專門管理應用程式的業務邏輯。Model、View、Controller三個層次的依賴關係如下：

依賴關係

Controller和View都依賴Model層，Controller和View可以互相依賴。在一些網上的資料Controller和View之間的依賴關係可能不一樣，有些是單向依賴，有些是雙向依賴，這個其實關係不大，後面會看到它們的依賴關係都是為了把處理使用者行為觸發的業務邏輯的處理權交給Controller。

MVC的呼叫關係

使用者的對View操作以後，View捕獲到這個操作，會把處理的權利交移給Controller（Pass calls）；Controller接著會執行相關的業務邏輯，這些業務邏輯可能需要對Model進行相應的操作；當Model變更了以後，會通過觀察者模式（Observer Pattern）通知View；View通過觀察者模式收到Model變更的訊息以後，會向Model請求最新的資料，然後重新更新介面。如下圖：

看似沒有什麼特別的地方，但是由幾個需要特別關注的關鍵點：

1、View是把控制權交移給Controller，自己不執行業務邏輯。

2、Controller執行業務邏輯並且操作Model，但不會直接操作View，可以說它是對View無知的。

3、View和Model的同步訊息是通過觀察者模式進行，而同步操作是由View自己請求Model的資料然後對檢視進行更新。

需要特別注意的是MVC模式的精髓在於第三點：Model的更新是通過觀察者模式告知View的，具體表現形式可以是Pub/Sub或者是觸發Events。而網上很多對於MVC的描述都沒有強調這一點。通過觀察者模式的好處就是：不同的MVC三角關係可能會有共同的Model，一個MVC三角中的Controller操作了Model以後，兩個MVC三角的View都會接受到通知，然後更新自己。保持了依賴同一塊Model的不同View顯示資料的實時性和準確性。我們每天都在用的觀察者模式，在幾十年前就已經被大神們整合到MVC的架構當中。

這裡有一個MVC模式的JavaScript Demo，實現了一個小的TodoList應用程式。經典的Smalltalk-80 MVC不需要任何框架支援就可以實現。目前Web前端框架當中只有一個號稱是嚴格遵循Smalltalk-80 MVC模式的：maria.js。

MVC的優缺點

優點：

1、把業務邏輯全部分離到Controller中，模組化程度高。當業務邏輯變更的時候，不需要變更View和Model，只需要Controller換成另外一個Controller就行了（Swappable Controller）。

2、觀察者模式可以做到多檢視同時更新。

缺點：

1、Controller測試困難。因為檢視同步操作是由View自己執行，而View只能在有UI的環境下執行。在沒有UI環境下對Controller進行單元測試的時候，Controller業務邏輯的正確性是無法驗證的：Controller更新Model的時候，無法對View的更新操作進行斷言。

2、View無法元件化。View是強依賴特定的Model的，如果需要把這個View抽出來作為一個另外一個應用程式可複用的元件就困難了。因為不同程式的的Domain Model是不一樣的

MVC Model 2

在Web服務端開發的時候也會接觸到MVC模式，而這種MVC模式不能嚴格稱為MVC模式。經典的MVC模式只是解決客戶端圖形介面應用程式的問題，而對服務端無效。服務端的MVC模式又自己特定的名字：MVC Model 2，或者叫JSP Model 2，或者直接就是Model 2 。Model 2客戶端服務端的互動模式如下：

服務端接收到來自客戶端的請求，服務端通過路由規則把這個請求交由給特定的Controller進行處理，Controller執行相應的業務邏輯，對資料庫資料（Model）進行操作，然後用資料去渲染特定的模版，返回給客戶端。

因為HTTP協議是單工協議並且是無狀態的，伺服器無法直接給客戶端推送資料。除非客戶端再次發起請求，否則伺服器端的Model的變更就無法告知客戶端。所以可以看到經典的Smalltalk-80 MVC中Model通過觀察者模式告知View更新這一環被無情地打破，不能稱為嚴格的MVC。

Model 2模式最早在1998年應用在JSP應用程式當中，JSP Model 1應用管理的混亂誘發了JSP參考了客戶端MVC模式，催生了Model 2。

後來這種模式幾乎被應用在所有語言的Web開發框架當中。PHP的ThinkPHP，Python的Dijango、Flask，NodeJS的Express，Ruby的RoR，基本都採納了這種模式。平常所講的MVC基本是這種服務端的MVC。

MVP

MVP模式有兩種：

1、Passive View

2、Supervising Controller

而大多數情況下討論的都是Passive View模式。本文會對PV模式進行較為詳細的介紹，而SC模式則簡單提及。

歷史背景

MVP模式是MVC模式的改良。在上個世紀90年代，IBM旗下的子公司Taligent在用C/C++開發一個叫CommonPoint的圖形介面應用系統的時候提出來的。

MVP（Passive View）的依賴關係

MVP模式把MVC模式中的Controller換成了Presenter。MVP層次之間的依賴關係如下：

MVP打破了View原來對於Model的依賴，其餘的依賴關係和MVC模式一致。

MVP（Passive View）的呼叫關係

既然View對Model的依賴被打破了，那View如何同步Model的變更？看看MVP的呼叫關係：

和MVC模式一樣，使用者對View的操作都會從View交移給Presenter。Presenter同樣的會執行相應的業務邏輯，並且對Model進行相應的操作；而這時候Model也是通過觀察者模式把自己變更的訊息傳遞出去，但是是傳給Presenter而不是View。Presenter獲取到Model變更的訊息以後，通過View提供的介面更新介面。

關鍵點：

1、View不再負責同步的邏輯，而是由Presenter負責。Presenter中既有業務邏輯也有同步邏輯。

2、View需要提供操作介面的介面給Presenter進行呼叫。（關鍵）

對比在MVC中，Controller是不能操作View的，View也沒有提供相應的介面；而在MVP當中，Presenter可以操作View，View需要提供一組對介面操作的介面給Presenter進行呼叫；Model仍然通過事件廣播自己的變更，但由Presenter監聽而不是View。

MVP模式，這裡也提供一個用JavaScript編寫的例子。

MVP（Passive View）的優缺點

優點：

1、便於測試。Presenter對View是通過介面進行，在對Presenter進行不依賴UI環境的單元測試的時候。可以通過Mock一個View物件，這個物件只需要實現了View的介面即可。然後依賴注入到Presenter中，單元測試的時候就可以完整的測試Presenter業務邏輯的正確性。這裡根據上面的例子給出了Presenter的單元測試樣例。

2、View可以進行元件化。在MVP當中，View不依賴Model。這樣就可以讓View從特定的業務場景中脫離出來，可以說View可以做到對業務邏輯完全無知。它只需要提供一系列介面提供給上層操作。這樣就可以做高度可複用的View元件。

缺點：

1、Presenter中除了業務邏輯以外，還有大量的View->Model，Model->View的手動同步邏輯，造成Presenter比較笨重，維護起來會比較困難。

MVP（Supervising Controller）

上面講的是MVP的Passive View模式，該模式下View非常Passive，它幾乎什麼都不知道，Presenter讓它幹什麼它就幹什麼。而Supervising Controller模式中，Presenter會把一部分簡單的同步邏輯交給View自己去做，Presenter只負責比較複雜的、高層次的UI操作，所以可以把它看成一個Supervising Controller。

Supervising Controller模式下的依賴和呼叫關係：

因為Supervising Controller用得比較少，對它的討論就到這裡為止。

MVVM

MVVM可以看作是一種特殊的MVP（Passive View）模式，或者說是對MVP模式的一種改良。

歷史背景

MVVM模式最早是微軟公司提出，並且了大量使用在.NET的WPF和Sliverlight中。2005年微軟工程師John Gossman在自己的部落格上首次公佈了MVVM模式。

ViewModel

MVVM代表的是Model-View-ViewModel，這裡需要解釋一下什麼是ViewModel。ViewModel的含義就是 “Model of View”，檢視的模型。它的含義包含了領域模型（Domain Model）和檢視的狀態（State）。在圖形介面應用程式當中，介面所提供的資訊可能不僅僅包含應用程式的領域模型。還可能包含一些領域模型不包含的檢視狀態，例如電子表格程式上需要顯示當前排序的狀態是順序的還是逆序的，而這是Domain Model所不包含的，但也是需要顯示的資訊。

可以簡單把ViewModel理解為頁面上所顯示內容的資料抽象，和Domain Model不一樣，ViewModel更適合用來描述View。

MVVM的依賴

MVVM的依賴關係和MVP依賴，只不過是把P換成了VM。

MVVM的呼叫關係

MVVM的呼叫關係和MVP一樣。但是，在ViewModel當中會有一個叫Binder，或者是Data-binding engine的東西。以前全部由Presenter負責的View和Model之間資料同步操作交由給Binder處理。你只需要在View的模版語法當中，指令式地宣告View上的顯示的內容是和Model的哪一塊資料繫結的。當ViewModel對進行Model更新的時候，Binder會自動把資料更新到View上去，當使用者對View進行操作（例如表單輸入），Binder也會自動把資料更新到Model上去。這種方式稱為：Two-way data-binding，雙向資料繫結。可以簡單而不恰當地理解為一個模版引擎，但是會根據資料變更實時渲染。