剛開始理解這些概念的時候認為這幾種模式雖然都是要將view和model解耦，但是非此即彼，沒有關(guān)系，一個應(yīng)用只會用一種模式。后來慢慢發(fā)現(xiàn)世界絕對不是只有黑白兩面，中間最大的一塊其實是灰色地帶，同樣，這幾種模式的邊界并非那么明顯，可能你在自己的應(yīng)用中都會用到。實際上也根本沒必要去糾結(jié)自己到底用的是MVC、MVP還是MVVP，不管黑貓白貓，捉住老鼠就是好貓。

MVC：Model-View-Controller
MVP：Model-View-Presenter
MVVM：Model-View-ViewModel
先說一下三者的共同點，也就是Model和View

Model就是領(lǐng)域模型，數(shù)據(jù)對象，同時，提供外部對應(yīng)用程序數(shù)據(jù)的操作的接口，也可能在數(shù)據(jù)變化時發(fā)出變更通知。Model不依賴于View的實現(xiàn)，只要外部程序調(diào)用Model的接口就能夠?qū)崿F(xiàn)對數(shù)據(jù)的增刪改查。
View就是UI層，提供對最終用戶的交互操作功能，包括UI展現(xiàn)代碼及一些相關(guān)的界面邏輯代碼。

三者的差異在于如何粘合View和Model，實現(xiàn)用戶的交互操作以及變更通知

Controller接收View的操作事件，根據(jù)事件不同，或者調(diào)用Model的接口進行數(shù)據(jù)操作，或者進行View的跳轉(zhuǎn)，從而也意味著一個Controller可以對應(yīng)多個View。Controller對View的實現(xiàn)不太關(guān)心，只會被動地接收，Model的數(shù)據(jù)變更不通過Controller直接通知View，通常View采用觀察者模式監(jiān)聽Model的變化。
Presenter，與Controller一樣，接收View的命令，對Model進行操作；與Controller不同的是Presenter會反作用于View，Model的變更通知首先被Presenter獲得，然后Presenter再去更新View。一個Presenter只對應(yīng)于一個View。根據(jù)Presenter和View對邏輯代碼分擔(dān)的程度不同，這種模式又有兩種情況：Passive View和Supervisor Controller。
ViewModel，注意這里的“Model”指的是View的Model，跟上面那個Model不是一回事。所謂View的Model就是包含View的一些數(shù)據(jù)屬性和操作的這么一個東東，這種模式的關(guān)鍵技術(shù)就是數(shù)據(jù)綁定（data binding），View的變化會直接影響ViewModel，ViewModel的變化或者內(nèi)容也會直接體現(xiàn)在View上。這種模式實際上是框架替應(yīng)用開發(fā)者做了一些工作，開發(fā)者只需要較少的代碼就能實現(xiàn)比較復(fù)雜的交互。

MVP和MVVM完全隔離了Model和View，但是在有些情況下，數(shù)據(jù)從Model到ViewModel或者Presenter的拷貝開銷很大，可能也會結(jié)合MVC的方式，Model直接通知View進行變更。在實際的應(yīng)用中很有可能你已經(jīng)在不知不覺中將幾種模式融合在一起，但是為了代碼的可擴展、可測試性，必須做到模塊的解耦，不相關(guān)的代碼不要放在一起。記得幾年前在上一家公司做一個新產(chǎn)品時，一名外包公司的新員工直接在View中做了數(shù)據(jù)庫持久化操作，而且一個hibernate代碼展開后發(fā)現(xiàn)竟然有幾百行的SQL語句，搞得我們驚訝不已，一時成為笑談。
個人理解，在廣義地談?wù)揗VC架構(gòu)時，并非指本文中嚴格定義的MVC，而是指的MV*，也就是視圖和模型的分離，只要一個框架提供了視圖和模型分離的功能，我們就可以認為它是一個MVC框架。在開發(fā)深入之后，可以再體會用到的框架到底是MVC、MVP還是MVVM。