對MVC、MVP、MVVM的理解
阿新 • • 發佈：2019-01-08
最近看了一堆js框架的文件，有點亂，想分門別類整理一下，但是首先需要搞清楚這些框架裡面經常談論的MV*之類的概念。MVC的概念很早就知道，現在發現還有MVP、MVVM，那麼這些設計模式有什麼區別呢？談一下自己的理解。
剛開始理解這些概念的時候認為這幾種模式雖然都是要將view和model解耦，但是非此即彼，沒有關係，一個應用只會用一種模式。後來慢慢發現世界絕對不是隻有黑白兩面，中間最大的一塊其實是灰色地帶，同樣，這幾種模式的邊界並非那麼明顯，可能你在自己的應用中都會用到。實際上也根本沒必要去糾結自己到底用的是MVC、MVP還是MVVP，不管黑貓白貓，捉住老鼠就是好貓。
MVC：Model-View-ControllerMVP：Model-View-Presenter
MVVM：Model-View-ViewModel
先說一下三者的共同點，也就是Model和View
- Model就是領域模型，資料物件，同時，提供外部對應用程式資料的操作的介面，也可能在資料變化時發出變更通知。Model不依賴於View的實現，只要外部程式呼叫Model的介面就能夠實現對資料的增刪改查。
- View就是UI層，提供對終端使用者的互動操作功能，包括UI展現程式碼及一些相關的介面邏輯程式碼。
三者的差異在於如何粘合View和Model，實現使用者的互動操作以及變更通知
- Controller接收View的操作事件，根據事件不同，或者呼叫Model的介面進行資料操作，或者進行View的跳轉，從而也意味著一個Controller可以對應多個View。Controller對View的實現不太關心，只會被動地接收，Model的資料變更不通過Controller直接通知View，通常View採用觀察者模式監聽Model的變化。
- Presenter，與Controller一樣，接收View的命令，對Model進行操作；與Controller不同的是Presenter會反作用於View，Model的變更通知首先被Presenter獲得，然後Presenter再去更新View。一個Presenter只對應於一個View。根據Presenter和View對邏輯程式碼分擔的程度不同，這種模式又有兩種情況：Passive View和Supervisor Controller。
- ViewModel，注意這裡的“Model”指的是View的Model，跟上面那個Model不是一回事。所謂View的Model就是包含View的一些資料屬性和操作的這麼一個東東，這種模式的關鍵技術就是資料繫結（data binding），View的變化會直接影響ViewModel，ViewModel的變化或者內容也會直接體現在View上。這種模式實際上是框架替應用開發者做了一些工作，開發者只需要較少的程式碼就能實現比較複雜的互動。
MVP和MVVM完全隔離了Model和View，但是在有些情況下，資料從Model到ViewModel或者Presenter的拷貝開銷很大，可能也會結合MVC的方式，Model直接通知View進行變更。在實際的應用中很有可能你已經在不知不覺中將幾種模式融合在一起，但是為了程式碼的可擴充套件、可測試性，必須做到模組的解耦，不相關的程式碼不要放在一起。記得幾年前在上一家公司做一個新產品時，一名外包公司的新員工直接在View中做了資料庫持久化操作，而且一個hibernate程式碼展開後發現竟然有幾百行的SQL語句，搞得我們驚訝不已，一時成為笑談。
個人理解，在廣義地談論MVC架構時，並非指本文中嚴格定義的MVC，而是指的MV*，也就是檢視和模型的分離，只要一個框架提供了檢視和模型分離的功能，我們就可以認為它是一個MVC框架。在開發深入之後，可以再體會用到的框架到底是MVC、MVP還是MVVM。
上面如有錯誤，敬請指出，謝謝。
參考資料：