一. MVC，MVP和MVVM誕生需求

MVC,MVP和MVVM都是用來解決界面呈現(xiàn)和邏輯代碼分離而出現(xiàn)的模式。
軟件中最核心的，最基本的東西是什么？是的，是數(shù)據(jù)。我們寫的所有代碼都是圍繞數(shù)據(jù)的產(chǎn)生，修改等變化出現(xiàn)了業(yè)務邏輯。
一般的代碼結(jié)構(gòu)從上到下依次是視圖層，業(yè)務邏輯層和數(shù)據(jù)層，而MVC、MVP和MVVM都是來解決視圖層和業(yè)務邏輯層的耦合。

二. MVC模式

MVC全名是Model View Controller，是模型（model）－視圖（view）－控制器（controller）的縮寫。MVC開始是存在于桌面程序中，使用MVC的目的是將M和V的實現(xiàn)代碼分離。

2.1 主動MVC

MVC的理論思想對應的是主動MVC，這里的主動的意思是Model會主動通知View更新。而我們使用的MVC框架，Struct、asp.net mvc等都不是主動MVC（視圖的更新都是通過Controller來完成的）。

Model

用于封裝與應用程序的業(yè)務邏輯相關的數(shù)據(jù)以及對數(shù)據(jù)的處理方法。
模型中數(shù)據(jù)的變化一般會通過一種刷新的機制被公布。為了實現(xiàn)這種機制，那些用于監(jiān)聽此模型的視圖必須事先在此模型上注冊，從而，視圖可以了解在數(shù)據(jù)模型上發(fā)生的變化。

View

視圖層負責數(shù)據(jù)的展示。
在視圖中一般沒有程序上的邏輯。為了實現(xiàn)視圖上的刷新功能，視圖需要訪問它監(jiān)視的數(shù)據(jù)模型（Model），因此應該事先在被它監(jiān)視的數(shù)據(jù)那里訂閱Model事件。

Controller

控制器是M和V之間的連接器，用于控制應用程序的流程。它處理事件并做出響應?！笆录卑ㄓ脩舻男袨楹蛿?shù)據(jù)模型上的改變。

220950360131856.png

2.2 被動MVC

下圖是被動MVC中的流程，和主動MVC不同之處是，View沒有訂閱Model數(shù)據(jù)變化的事件，等待Model來通知需要根據(jù)新的數(shù)據(jù)來更新View。在被動MVC中，Controller負責通知View，有數(shù)據(jù)變化，需要更新視圖。

220950371071953.png

被動MVC與主動MVC的區(qū)別：

1. 模型對視圖和控制器一無所知，僅僅是被他們使用
2. 控制器使用視圖，并通知它更新數(shù)據(jù)顯示
3. 視圖僅僅是在控制器通知它去模型取數(shù)據(jù)的時候它才這么做（視圖并不會訂閱或監(jiān)視模型的更新）

2.3 MVC優(yōu)點

＊耦合性低
＊開發(fā)速度快
＊可維護性高

2.4 MVC使用的誤區(qū)

1. 把Model理解成實體類（Entity），在MVC中Model應該包含2部分功能，一部分是處理業(yè)務邏輯，一部分是提供View顯示的數(shù)據(jù)
2. 把業(yè)務邏輯全部放在Controller中
   這兩個誤區(qū)本質(zhì)上都是對Model的作用不明導致的
   Model在MVC架構(gòu)中起的作用非常重要，他應該是業(yè)務邏輯真正的實現(xiàn)層。所以Model實際上是Business Model（業(yè)務模型），而Controller僅僅起一個“橋梁”的作用，它負責把View的請求轉(zhuǎn)發(fā)給Model，再負責把Model處理技術的消息通知View。Controller是用來解耦View和Model的

2.5 MVC的缺點

完美的MVC應用場景應該是這樣的：
有個Student Model，關聯(lián)StudentListView，StudentEditView
對于StudentListView，Student Model提供Student的集合數(shù)據(jù)來顯示StudentListView
對于StudentEditView，Student Model提供單個Student數(shù)據(jù)來展示StudentEditView并且響應StudentEditView的保存操作

但是這只是完美的情況，實際應用中，在ListView上，不單單顯示Student的信息，可能需要這個Student的歷史成績，家庭情況，老師信息，而這些是Student Model不能提供的
也許我們可以擴展Student Model，將Student Model能夠提供的信息擴展，包含成績信息等，這本身也可以。但是，如果Student顯示的View，只是需要額外的成績信息，另一個View制式需要額外的家庭信息，Student Model是不是有些疲于奔命，你能知道還有多少個差異化的View的需求？而且讓邏輯段代碼這樣不斷的修改來適應View 端，好嗎？
由于MVC的設計思想是從Model出發(fā)，而沒有考慮到View端的復雜性，這樣導致的問題是Model難以符合復雜多變的View端變化。
相對這點，MVP和MVVM就要好得多。它們都獨立了Presenter和ViewModel來對應沒個View。

原文鏈接：http://www.cnblogs.com/JustRun1983/p/3679827.html

三、MVP模式

MVP模式也是一種經(jīng)典的界面模式。MVP中的M代表Model，V是View，P是Presenter。

3.1 MVP的思想

MVP模式在我看來，是一個真正意義上的隔離View細節(jié)和復雜性的模式。為什么這么說呢？
因為在其它模式中V都代表的是UI界面，但是在MVP模式中代表的是一個接口，一個將UI界面提煉而抽象出來的接口。接口意味著任何實現(xiàn)了該接口的界面，都能夠復用已有的Presenter和Model代碼

3.2 UI界面接口化

要很好的理解MVP，就要有把UI界面接口化的能力?？聪旅娴慕缑嬷校瑢⒓t色標記的User Control抽象一下，就能得到下面的接口

141349045464079.png

public interface IUserAdd 
{ 
   event EventHandler UserAddEvent;
   string UserName { get; set; }
   string UserAge { get; set; }
}

界面中的2個輸入框被抽象成了UserName和UserAge兩個屬性。Save按鈕的點擊事件被抽象成了事件UserAddEvent。winform中實現(xiàn)該接口的代碼如下：

   public partial class UserAdd : UserControl, IUserAdd 
   { 
       public event EventHandler UserAddEvent; 
       public string UserName 
       { 
         set { this.txbName.Text = value; } 
         get { return this.txbName.Text; } 
     }

     public string UserAge 
     { 
         set { this.txbAge.Text = value; } 
         get { return this.txbAge.Text; } 
     }

     public UserAdd() 
     { 
         InitializeComponent(); 
     }
     private void btnAdd_Click(object sender, EventArgs e) 
     { 
        if (UserAddEvent != null) UserAddEvent(this, e); 
     } 
   }

下面拿UserAge屬性來解釋一下，UI界面接口化的魔力。當后端代碼要獲取界面上的年齡值，就只需要get屬性，要更新界面顯示的時候，就只需要set屬性。這個時候，后端代碼對于界面的操作，被抽象成了對于UserAge屬性的操作了，也就是和具體的界面顯示無關了。

3.3 Presenter－Model和View之間的橋梁

針對上面的IUserAdd，對應的Prensenter代碼是：

public class UserAddPresenter:IPresenter
{
private readonly IUser _model;
private readonly IUserAdd _view;
private readonly ApplicationFacade _facade = ApplicationFacade.Instance; //這里的facade是Presenter之間通信用的，詳細可以看完整代碼

  //Presenter構(gòu)造函數(shù)中，將view和model作為參數(shù)傳入

   public UserAddPresenter(IUser model, IUserAdd view) 
   { 
       _model = model; 
       _view = view; 
       WireUpViewEvents(); 
   }

   private void WireUpViewEvents() 
   { 
       _view.UserAddEvent += _view_UserAdd; 
   }

  //當view的UserAdd事件觸發(fā)，取得UI中的數(shù)據(jù)，調(diào)用model邏輯處理，添加新用戶。
 //同時發(fā)送User_ADDED消息到系統(tǒng)中(系統(tǒng)中其它UI部分接收消息，比如這里的DataGrid，它接收到User_ADDED之后，會刷新)
   private void _view_UserAdd(object sender, EventArgs e) 
   { 
       var user = new User 
                  { 
                      Name = _view.UserName, 
                      Age = Convert.ToInt32(_view.UserAge) 
                  };
       _model.AddItem(user); 
       _facade.SendNotification(ApplicationFacade.USER_ADDED); 
   }
}

3.4 MVP的代碼結(jié)構(gòu)和時序圖

這里的MVP中的代碼結(jié)構(gòu)圖和時序圖，能夠更好的幫助理解MVP模式

141349081564481.png

141349138756727.png

3.5 MVP模式總結(jié)

在MVP里，Presenter完全把Model和View進行了分離，主要的程序邏輯在Presenter里實現(xiàn)。而且，Presenter與具體的View是沒有只直接關聯(lián)的，而是通過定義好的接口進行交互，從而使得在變更View的時候可以保持Presenter的不變，即重用！不僅如此，我們還可以編寫測試用的View，模擬用戶的各種操作，從而實現(xiàn)對Presenter的測試－而不需要使用自動化的測試工具。我們甚至可以在Model和View都沒有完成的時候，就可以通過編寫Mock Object（即實現(xiàn)了Model和View的接口，但沒有具體內(nèi)容）來測試Presenter的邏輯。

MVP的優(yōu)勢

1. 模擬與視圖完全分離，我們可以修改視圖而不影響模型
2. 可以更高效的使用模型，因為所有的交互都發(fā)生在一個地方－Presenter內(nèi)部
3. 我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁。
4. 如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶界面來測試這些邏輯（單元測試）

四、MVVM模式

4.1 MVVM模式的設計思想

MVVM模式中，一個ViewModel和一個View匹配，它沒有MVP中的IView接口，而是完全的和View綁定，所有View中的修改變化，都會自動更新到ViewModel中，同時ViewModel的任何變化也會自動同步到View上顯示。
這種自動同步之所以能夠的原因是ViewModel中的屬性都實現(xiàn)了observable這樣的接口，也就是說當使用屬性的set方法，都會同時觸發(fā)屬性修改的事件，使綁定的UI自動刷新。
所以MVVM比MVP更升級一步，在MVP中，V是接口IView，解決對于界面UI的耦合；而MVVM干脆直接使用ViewModel和UI的無縫結(jié)合，ViewModel直接就能代表UI。但是MVVM做到這點是要依賴具體的平臺和技術實現(xiàn)的，這也就是為什么ViewModel不需要實現(xiàn)接口的原因，因為對于具體平臺和技術的依賴，本質(zhì)上使用MVVM模式就是不能替換UI的使用平臺

4.2 MVVM模式結(jié)構(gòu)圖

這里是MVVM模式的結(jié)構(gòu)圖，能夠幫助更加容易的理解MVVM模式

141349167032958.jpg

來源：http://www.cnblogs.com/JustRun1983/p/3727560.html