一. MVC，MVP和MVVM誕生需求
MVC,MVP和MVVM都是用來解決界面呈現(xiàn)和邏輯代碼分離而出現(xiàn)的模式。
軟件中最核心的，最基本的東西是什么？是的，是數(shù)據(jù)。我們寫的所有代碼都是圍繞數(shù)據(jù)的產(chǎn)生，修改等變化出現(xiàn)了業(yè)務(wù)邏輯。
一般的代碼結(jié)構(gòu)從上到下依次是視圖層，業(yè)務(wù)邏輯層和數(shù)據(jù)層，而MVC、MVP和MVVM都是來解決視圖層和業(yè)務(wù)邏輯層的耦合。
二. MVC模式
MVC全名是Model View Controller，是模型（model）－視圖（view）－控制器（controller）的縮寫。MVC開始是存在于桌面程序中，使用MVC的目的是將M和V的實現(xiàn)代碼分離。
2.1 主動MVC
MVC的理論思想對應(yīng)的是主動MVC，這里的主動的意思是Model會主動通知View更新。而我們使用的MVC框架，Struct、asp.net mvc等都不是主動MVC（視圖的更新都是通過Controller來完成的）。
Model
用于封裝與應(yīng)用程序的業(yè)務(wù)邏輯相關(guān)的數(shù)據(jù)以及對數(shù)據(jù)的處理方法。
模型中數(shù)據(jù)的變化一般會通過一種刷新的機(jī)制被公布。為了實現(xiàn)這種機(jī)制，那些用于監(jiān)聽此模型的視圖必須事先在此模型上注冊，從而，視圖可以了解在數(shù)據(jù)模型上發(fā)生的變化。
View
視圖層負(fù)責(zé)數(shù)據(jù)的展示。
在視圖中一般沒有程序上的邏輯。為了實現(xiàn)視圖上的刷新功能，視圖需要訪問它監(jiān)視的數(shù)據(jù)模型（Model），因此應(yīng)該事先在被它監(jiān)視的數(shù)據(jù)那里訂閱Model事件。
Controller
控制器是M和V之間的連接器，用于控制應(yīng)用程序的流程。它處理事件并做出響應(yīng)。“事件”包括用戶的行為和數(shù)據(jù)模型上的改變。
2.2 被動MVC
下圖是被動MVC中的流程，和主動MVC不同之處是，View沒有訂閱Model數(shù)據(jù)變化的事件，等待Model來通知需要根據(jù)新的數(shù)據(jù)來更新View。在被動MVC中，Controller負(fù)責(zé)通知View，有數(shù)據(jù)變化，需要更新視圖。
被動MVC與主動MVC的區(qū)別：
- 模型對視圖和控制器一無所知，僅僅是被他們使用
- 控制器使用視圖，并通知它更新數(shù)據(jù)顯示
- 視圖僅僅是在控制器通知它去模型取數(shù)據(jù)的時候它才這么做（視圖并不會訂閱或監(jiān)視模型的更新）
2.3 MVC優(yōu)點(diǎn)
＊耦合性低
＊開發(fā)速度快
＊可維護(hù)性高
2.4 MVC使用的誤區(qū)
- 把Model理解成實體類（Entity），在MVC中Model應(yīng)該包含2部分功能，一部分是處理業(yè)務(wù)邏輯，一部分是提供View顯示的數(shù)據(jù)
- 把業(yè)務(wù)邏輯全部放在Controller中
這兩個誤區(qū)本質(zhì)上都是對Model的作用不明導(dǎo)致的
Model在MVC架構(gòu)中起的作用非常重要，他應(yīng)該是業(yè)務(wù)邏輯真正的實現(xiàn)層。所以Model實際上是Business Model（業(yè)務(wù)模型），而Controller僅僅起一個“橋梁”的作用，它負(fù)責(zé)把View的請求轉(zhuǎn)發(fā)給Model，再負(fù)責(zé)把Model處理技術(shù)的消息通知View。Controller是用來解耦View和Model的
2.5 MVC的缺點(diǎn)
完美的MVC應(yīng)用場景應(yīng)該是這樣的：
有個Student Model，關(guān)聯(lián)StudentListView，StudentEditView
對于StudentListView，Student Model提供Student的集合數(shù)據(jù)來顯示StudentListView
對于StudentEditView，Student Model提供單個Student數(shù)據(jù)來展示StudentEditView并且響應(yīng)StudentEditView的保存操作
但是這只是完美的情況，實際應(yīng)用中，在ListView上，不單單顯示Student的信息，可能需要這個Student的歷史成績，家庭情況，老師信息，而這些是Student Model不能提供的
也許我們可以擴(kuò)展Student Model，將Student Model能夠提供的信息擴(kuò)展，包含成績信息等，這本身也可以。但是，如果Student顯示的View，只是需要額外的成績信息，另一個View制式需要額外的家庭信息，Student Model是不是有些疲于奔命，你能知道還有多少個差異化的View的需求？而且讓邏輯段代碼這樣不斷的修改來適應(yīng)View 端，好嗎？
由于MVC的設(shè)計思想是從Model出發(fā)，而沒有考慮到View端的復(fù)雜性，這樣導(dǎo)致的問題是Model難以符合復(fù)雜多變的View端變化。
相對這點(diǎn)，MVP和MVVM就要好得多。它們都獨(dú)立了Presenter和ViewModel來對應(yīng)沒個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細(xì)節(jié)和復(fù)雜性的模式。為什么這么說呢？
因為在其它模式中V都代表的是UI界面，但是在MVP模式中代表的是一個接口，一個將UI界面提煉而抽象出來的接口。接口意味著任何實現(xiàn)了該接口的界面，都能夠復(fù)用已有的Presenter和Model代碼
3.2 UI界面接口化
要很好的理解MVP，就要有把UI界面接口化的能力。看下面的界面中，將紅色標(biāo)記的User Control抽象一下，就能得到下面的接口
public interface IUserAdd
{
event EventHandler UserAddEvent;
string UserName { get; set; }
string UserAge { get; set; }
}
界面中的2個輸入框被抽象成了UserName和UserAge兩個屬性。Save按鈕的點(diǎn)擊事件被抽象成了事件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界面接口化的魔力。當(dāng)后端代碼要獲取界面上的年齡值，就只需要get屬性，要更新界面顯示的時候，就只需要set屬性。這個時候，后端代碼對于界面的操作，被抽象成了對于UserAge屬性的操作了，也就是和具體的界面顯示無關(guān)了。
3.3 Presenter－Model和View之間的橋梁
針對上面的IUserAdd，對應(yīng)的Prensenter代碼是：
public class UserAddPresenter:IPresenter
{
private readonly IUser _model;
private readonly IUserAdd _view;
private readonly ApplicationFacade _facade = ApplicationFacade.Instance; //這里的facade是Presenter之間通信用的，詳細(xì)可以看完整代碼
//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;
}
//當(dāng)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模式
3.5 MVP模式總結(jié)
在MVP里，Presenter完全把Model和View進(jìn)行了分離，主要的程序邏輯在Presenter里實現(xiàn)。而且，Presenter與具體的View是沒有只直接關(guān)聯(lián)的，而是通過定義好的接口進(jìn)行交互，從而使得在變更View的時候可以保持Presenter的不變，即重用！不僅如此，我們還可以編寫測試用的View，模擬用戶的各種操作，從而實現(xiàn)對Presenter的測試－而不需要使用自動化的測試工具。我們甚至可以在Model和View都沒有完成的時候，就可以通過編寫Mock Object（即實現(xiàn)了Model和View的接口，但沒有具體內(nèi)容）來測試Presenter的邏輯。
MVP的優(yōu)勢
- 模擬與視圖完全分離，我們可以修改視圖而不影響模型
- 可以更高效的使用模型，因為所有的交互都發(fā)生在一個地方－Presenter內(nèi)部
- 我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁。
- 如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶界面來測試這些邏輯（單元測試）
四、MVVM模式
4.1 MVVM模式的設(shè)計思想
MVVM模式中，一個ViewModel和一個View匹配，它沒有MVP中的IView接口，而是完全的和View綁定，所有View中的修改變化，都會自動更新到ViewModel中，同時ViewModel的任何變化也會自動同步到View上顯示。
這種自動同步之所以能夠的原因是ViewModel中的屬性都實現(xiàn)了observable這樣的接口，也就是說當(dāng)使用屬性的set方法，都會同時觸發(fā)屬性修改的事件，使綁定的UI自動刷新。
所以MVVM比MVP更升級一步，在MVP中，V是接口IView，解決對于界面UI的耦合；而MVVM干脆直接使用ViewModel和UI的無縫結(jié)合，ViewModel直接就能代表UI。但是MVVM做到這點(diǎn)是要依賴具體的平臺和技術(shù)實現(xiàn)的，這也就是為什么ViewModel不需要實現(xiàn)接口的原因，因為對于具體平臺和技術(shù)的依賴，本質(zhì)上使用MVVM模式就是不能替換UI的使用平臺
4.2 MVVM模式結(jié)構(gòu)圖
這里是MVVM模式的結(jié)構(gòu)圖，能夠幫助更加容易的理解MVVM模式
