MVC框架模式
MVC是一種框架模式而非設計模式，GOF把MVC看作是3種設計模式：觀察者模式、策略模式與組合模式的合體，而核心是觀察者模式。
當用戶出發事件的時候，view層會發送指令到controller層，接着controller去通知model層更新數據，model層更新完數據以後直接顯示在view層上，這就是MVC的工作原理。
MVC（Model-View-Controller），它將應用程序劃分爲三個部分：
- 模型Model: 數據塊（用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法）
- 視圖View: 用戶界面
- 控制器Controller: 業務邏輯控制器（M和V之間的連接器，用於控制應用程序的流程，及頁面的業務邏輯）
優缺點
優點
- 模塊化了，將業務邏輯、數據處理與界面顯示進行分離
缺點
- View依賴特定的Model，無法組件化
- 主要業務邏輯都在Controller中，Controller會變得很重
- View和Controller緊耦合，如果脫離Controller，View難以獨立應用（功能太少）
在MVC裏，View是可以直接訪問Model的！從而，View裏會包含Model信息，不可避免的還要包括一些業務邏輯。 在MVC模型裏，更關注的Model的不變，而同時有多個對Model的不同View顯示。所以，在MVC模型裏，Model不依賴於View，但是View是依賴於Model的。不僅如此，因爲有一些業務邏輯在View裏實現了，導致要更改View也是比較困難的，至少那些業務邏輯是無法重用的。
MVP框架模式
MVP（Model-View-Presenter）跟MVC很相像，最大的差別是Model和View之間不進行通訊，都是通過Presenter完成。
Presenter與具體的View是沒有直接關聯的，而是通過定義好的接口進行交互，從而使得在變更View時候可以保持Presenter的不變，這樣就可以重用。Presenter與View的交互是通過接口來進行的。
View向Presenter發起調用請求，Presenter修改Model，Model修改完成後通知Presenter，Presenter再調用View的相關接口刷新界面。這樣，View就不需要監聽具體Model的變化了，只需要提供接口給Presenter調用就可以了。
優缺點
優點
- MVP模式會解除View與Model的耦合，有效的降低View的複雜性，我們可以修改視圖而不影響模型；同時又帶來了可擴展性、可測試性。
- 如果我們把邏輯放在Presenter中，那麼我們就可以脫離用戶接口來測試這些邏輯（單元測試）。
缺點
- 在不使用接口的情況下，視圖和Presenter的交互會過於頻繁，使得他們的聯繫過於緊密。也就是說，一旦視圖變更了，presenter也要變更。
比較
MVC的耦合性還是較高的，View可以直接訪問Model，導致3者之間構成了迴路。所以兩者的主要區別是，MVP中View不能直接訪問Model，需要通過Presenter發出請求，View與Model不能直接通信。
MVVM框架模式
VM層：ViewModel，即 View的數據模型和Presenter的合體
ViewModel大致上就是MVP的Presenter和MVC的Controller了，而View和ViewModel間沒有了MVP的界面接口，而是直接交互，用數據“綁定”的形式讓數據更新的事件不需要開發人員手動去編寫特殊用例，而是自動地雙向同步。數據綁定你可以認爲是Observer模式或者是Publish/Subscribe模式，原理都是爲了用一種統一的集中的方式實現頻繁需要被實現的數據更新問題。
MVVM與MVP非常相似，唯一區別是View和ViewModel進行雙向綁定，兩者之間有一方發生變化則會反應到另一方上。
優缺點
- 低耦合，視圖（View）可以獨立於Model變化和修改，一個ViewModel可以綁定到不同的”View”上，當View變化的時候Model可以不變，當Model變化的時候View也可以不變。
- 可重用性，可以把一些視圖邏輯放在一個ViewModel裏面，讓很多view重用這段視圖邏輯。
- 可測試，界面向來是比較難於測試的，而現在測試可以針對ViewModel來寫。
- 比起MVP，MVVM不僅簡化了業務與界面的依賴關係，還優化了數據頻繁更新的解決方案，甚至可以說提供了一種有效的解決模式。
DataBinding
DataBinding是谷歌官方發佈的一個框架，顧名思義即爲數據綁定，是MVVM模式在Android上的一種實現，用於降低佈局和邏輯的耦合性，使代碼邏輯更加清晰。DataBinding其實並沒有實現新的API來完成雙向綁定，只是對原有API的封裝，如findViewById()和setText()，亦或是click事件，這些都被框架隱藏起來了。至於這些事件的觸發，例如View層接收到點擊事件並通知ViewModel層，則是使用發佈訂閱模式實現的，如下圖：
每當View層更改時，ViewModel層通過訂閱收到通知；每當ViewModel層更改時，View層也會通過訂閱收到通知，這樣就實現了雙向綁定。
這裏可能會出現一個循環問題，假設其中某一層A改變，那麼另外一層B得到通知隨之改變，這會導致A層得到通知，A層也改變，循環往復出現問題。
DataBinding通過前後數據對比來決定是否更新，假設View層需要更新文本信息（如TextView），則DataBinding會對比當前的文本和更新的文本，如果不一致則進行更新操作；如果相同，則不做任何操作。其他的控件也有類似的判定操作，這樣就解決了數據雙向綁定中的循環問題。
三種模式出現的初衷
MVC模式的出現
爲解決程序模塊化問題，於是MVC模式出現了：將業務邏輯、數據處理與界面顯示進行分離來組織代碼，即分成M、V、C層；
MVP模式的出現
但M、V層還是有相互交叉、隔離度不夠，於是出現了MVP： 隔離了MVC中的 M 與 V 的直接聯繫，將M、V層更加隔離開來；
MVVM模式的出現
爲了更加分離M、V層，於是出現了MVVM： 使得V和M層之間的耦合程度進一步降低，分離更爲徹底。
區別
先說一下三者的共同點，也就是Model和View
- Model就是領域模型，數據對象，同時，提供外部對應用程序數據的操作的接口，也可能在數據變化時發出變更通知。Model不依賴於View的實現，只要外部程序調用Model的接口就能夠實現對數據的增刪改查。
- View就是UI層，提供對用戶的交互操作功能，包括UI展現代碼及一些相關的界面邏輯代碼。
三者的差異在於如何粘合View和Model，實現用戶的交互操作以及變更通知。M-V-X本質都是一樣的,重點還是在於M-V的橋樑,要靠X來牽線。
- 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進行變更。在實際的應用中很有可能你已經在不知不覺中將幾種模式融合在一起，但是爲了代碼的可擴展、可測試性，必須做到模塊的解耦，不相關的代碼不要放在一起。
分化是一種需求的必然結果，但卻沒有個一個確定的結果。MVC順着需求把UI相關的工作分化成了三份，這點經過實踐證明無可厚非。但是它們的三角關係卻被一些人認爲帶來了一些問題，或者應該說他們有“更好的”解決方案。在MVC，當你有變化的時候你需要同時維護三個對象和三個交互，這顯然讓事情複雜化了。