MVC的概念很早就知道，現在發現還有MVP、MVVM，那麼這些設計模式有什麼區別呢？談一下自己的理解。
剛開始理解這些概念的時候認爲這幾種模式雖然都是要將view和model解耦，但是非此即彼，沒有關係，一個應用只會用一種模式。後來慢慢發現世界絕對不是隻有黑白兩面，中間最大的一塊其實是灰色地帶，同樣，這幾種模式的邊界並非那麼明顯，可能你在自己的應用中都會用到。實際上也根本沒必要去糾結自己到底用的是MVC、MVP還是MVVP，不管黑貓白貓，捉住老鼠就是好貓。
MVC：Model-View-Controller
MVP：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框架。