白話 MVC、MVP、MVVP

注意這裏單純的經過例子來說解 MVC MVP MVVP 這三種架構模式的起源和做用，不牽扯某種特定的語言。具體到各類語言各類軟件系統上體現有所不一樣，可是原理都是這樣的。清楚原理最重要java

假設要開發一款軟緣分指數軟件，軟件以下圖：程序員

輸入男生姓名和女生姓名後，點擊按鈕便可計算出緣分指數，就是這麼一個軟件。固然自己這個軟件很是簡單，可是爲了更好的演示，不可能真的舉出一個大項目的例子，因爲這個軟件自己過於簡單，真正設計架構的話反而顯得很雞肋，所以你要想象成這個軟件十分複雜！否則容易產生這麼設計架構有什麼用的想法。markdown

起始階段

最初階段，程序員小明寫這個軟件的時候什麼都沒有想，直接上手碼代碼了，結果用於展現頁面的代碼，用於獲取用戶輸入內容的代碼，拿到用戶輸入的內容來計算緣分指數的代碼，等等代碼業務所有寫在了一個文件中。完成了本軟件的開發。網絡

結果過了一段時間小明離職了，小華來接手他的代碼，小華看到這個代碼的時候，默默的留下了眼淚，一個文件中足足有 1 萬多行代碼，各類功能的代碼彼此混合在一塊兒，徹底是大雜燴，想要修改一個地方根本不敢動。因而小華決定本身從新來寫，由於這個大雜燴已經不可能維護了，改動比重寫代價還要大！數據結構

MVC

小華是這樣給這個程序分類的：架構

首先是頁面，頁面能夠單獨抽離出來
一些和頁面判斷有關的邏輯，好比：若是什麼也沒有填寫的話，點擊按鈕是不會進行業務計算的。獲取用戶輸入後去調用具體的業務邏輯的操做
具體的計算緣分指數的的業務（須要查詢大量數據得出）

頁面部分用 V 來表明，只負責與頁面有關的操做，好比按鈕的擺放位置，計算出結果後頁面的變化更新等等與頁面有關的操做。框架

控制頁面上的邏輯和調用具體業務邏輯的操做用 C 來表明，在 C 中只負責接收 V 的指令，而後調用業務邏輯，和操做 V單元測試

計算具體的與數據有關的業務邏輯用 M 來表示。測試

小華就按照這種方式來進行書寫代碼，這樣寫出來的代碼可讀性很是高，各層之間互相分離，再也不是大雜燴了。並且分工也容易，寫頁面的寫頁面，寫業務邏輯的寫業務邏輯等等。優化

上面這樣設計的流程圖是這樣的：

固然，你在網上能夠還看到過其餘的設計圖，各類各樣的都有，其實這個就看做者是怎麼想的了，這個沒有標準答案。主要的思想就是分層了，再也不大雜燴了，至於它們之間的相互關係，就看你具體代碼的體現了。

其實 MVC 在真正大型運用的時候，最接近這種

也就是說若是不觸及複雜邏輯或者數據的狀況下，一些簡單邏輯就直接在 Controller 處理了，而後 Controller 再做用於 View 。還有一點就是 MVC 中 View 是能夠和 Model 直接進行交流的。

固然若是你非要切斷 Model 和 View 之間的關係的話，那樣就演變成 MVP 了。

這就是 MVC 的雛形

M 表示 Model 專門用來作一些和數據（聯網數據、本地數據、複雜邏輯）有關的邏輯

V 表示 View 專門用來控制頁面的

C 表示 Controller 獲取用戶的輸入，操做 M 和 V，說白了就是調用 M 和 V 中的方法

MVP

又過了一段時間，小華髮現這種架構方式雖然比以前的大雜燴好不少，可是 M V C 之間相互依賴過多，因爲 View 能夠和 Model 直接通訊，這就形成了 View 既依賴於 Controller 又依賴於 Model 。Controller 一樣依賴於 View 和 Model。耦合性仍是過高，因而進行了進一步的優化處理。讓 M 和 V 完全斷了聯繫，只經過 P 來進行通訊。

這樣 P 操做 Model，在 Model 中進行業務計算後得出結果，讓Presenter 再去更新 View。

public void updateView(){
    view.setText("xxxxxx");
}
複製代碼

這樣Presenter 對 View 有依賴，這樣 Presenter 就無法進行單獨作單元測試了，必須等頁面好了之後才能夠（否則無法調用頁面裏面的方法）。因而進一步優化，讓 View 層提出接口，Presenter 只依賴這個接口（接口很好寫），這樣頁面還有完成也能夠進行測試了。

經過接口也下降了耦合性，其餘的頁面也能夠實現這個接口。

MVVM

MVP 使用一段時間後，發現讓 Presenter 調用 View 的方法去設置界面，仍然須要大量的、煩人的代碼。

因而提出：能不能告訴 View 一個數據結構，而後 View 就能根據這個數據結構變化而自動隨之變化呢？

因而有了一個叫 ViewModel 的東西，它能夠和 View 層綁定。ViewModel 的變化，View 馬上就會變化。

那麼什麼是 ViewModel 呢？繼續拿上面那個例子舉例，ViewModel 差很少是這樣的：

public class SalaryViewModel{
    String sex; // 性別，和 View 中的相關字段對應
    String index; // 姻緣指數，和 View 中的相關字段對應
  
    //.....
}
複製代碼

當用戶在界面上點擊「計算」按鈕的時候，只須要對 ViewModel 作出改變就好了。View 會根據 ViewModel 的變化作出更新，不用手工去設置。

ViewModel 和 View 的綁定問題，須要開發一個框架讓二者綁定起來，微軟的 WPF 和 Silverlight，Android 等框架和系統均可以實現 View 和 ViewModel 之間的映射和綁定。

到此整個架構的設計就很是合理了，代碼維護起來也比較容易，可閱讀行比較高！

總結

再次強調上面講的都是 MVC MVP MVVP 大的設計思路，具體到不一樣的語言程序體現起來是不一樣的，沒有準確的定義，具體的書寫方式要根據開發者本身的思想來定義。目的就是讓代碼不一樣功能間相互獨立，可閱讀性強，便於擴充和重複利用。

一切不結合項目和實際問題空談架構的行爲都是耍流氓

切記不能爲了架構而架構，項目較小的狀況下，硬搬亂套架構只會增長你的代碼量，致使很是冗餘，這種狀況下還不如好好提煉幾個方法更容易查看維護。

起初寫的代碼所有混合在一塊兒很是冗餘不便於維護（固然若是說你寫的時候作了某種抽離和分層，那麼這就是你的一種架構思想），爲了解決這個問題提出了 MVC 的架構模式，極大的解決了混爲一灘的狀況，可是這種思想設計之初 M 和 V 之間是能夠相互通訊的，致使了依賴關係太多，就出現了 MVP，MVP 出現後解決了 M 和 V 之間通訊的狀況，讓 M 和 V 完全失去關係，由 P 來通知 V 進行修改，再後來每次 P 還要通知 V 進行修改太麻煩就想法當 M 中的數據發生變化的時候直接修改 V 中的視圖經過 ViewModle 來實現，這個時候就出現了 MVVM。

下面一篇文章來說解這幾種模式在 Android 開發中的具體體現。