mvc全名是model view controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟體設計典範，用一種業務邏輯、資料、界面顯示分離的方法組織代碼，将業務邏輯聚集到一個部件裡面，在改進和個性化定制界面及使用者互動的同時，不需要重新編寫業務邏輯。mvc被獨特的發展起來用于映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化使用者界面的結構中。
view 接受使用者互動請求
view 将請求轉交給controller
controller 操作model進行資料更新
資料更新之後，model通知view更新資料變化
view 更新變化資料
所有方式都是單向通信
view ：使用 composite模式
view和controller：使用 strategy模式
model和 view：使用 observer模式同步資訊
mvc中的view是可以直接通路model的！進而，view裡會包含model資訊，不可避免的還要包括一些業務邏輯。在mvc模型裡，更關注的model的不變，而同時有多個對model的不同顯示，及view。是以，在mvc模型裡，model不依賴于view，但是 view是依賴于model的。不僅如此，因為有一些業務邏輯在view裡實作了，導緻要更改view也是比較困難的，至少那些業務邏輯是無法重用的。
mvp的全稱為model-view-presenter，model提供資料，view負責顯示，controller/presenter負責邏輯的處理。mvp與mvc有着一個重大的差別：在mvp中view并不直接使用model，它們之間的通信是通過presenter (mvc中的controller)來進行的，所有的互動都發生在presenter内部，而在mvc中view會直接從model中讀取資料而不是通過 controller。
view 接收使用者互動請求
view 将請求轉交給 presenter
presenter 操作model進行資料更新
model 通知presenter資料發生變化
presenter 更新view資料
model與view完全分離，修改互不影響
更高效地使用，因為所有的邏輯互動都發生在一個地方—presenter内部
一個preseter可用于多個view，而不需要改變presenter的邏輯（因為view的變化總是比model的變化頻繁）。
更便于測試。把邏輯放在presenter中，就可以脫離使用者接口來測試邏輯（單元測試）
各部分之間都是雙向通信
view和presenter：使用 mediator模式
model和presenter：使用 command模式同步資訊
mvp與mvc最大的一個差別就是：model與view層之間倒底該不該通信（甚至雙向通信）
mvp的實作會根據view的實作而有一些不同，一部分傾向于在view中放置簡單的邏輯，在presenter放置複雜的邏輯；另一部分傾向于在presenter中放置全部的邏輯。這兩種分别被稱為：passive view和superivising controller。
mvvm是model-view-viewmodel的簡寫。微軟的wpf帶來了新的技術體驗，如silverlight、音頻、視訊、3d、動畫……，這導緻了軟體ui層更加細節化、可定制化。同時，在技術層面，wpf也帶來了 諸如binding、dependency property、routed events、command、datatemplate、controltemplate等新特性。mvvm（model-view-viewmodel）架構的由來便是mvp（model-view-presenter）模式與wpf結合的應用方式時發展演變過來的一種新型架構架構。它立足于原有mvp架構并且把wpf的新特性糅合進去，以應對客戶日益複雜的需求變化。
view 将請求轉交給viewmodel
viewmodel 操作model資料更新
model 更新完資料，通知viewmodel資料發生變化
viewmodel 更新view資料
雙向綁定。view/model的變動，自動反映在 viewmodel，反之亦然。
可以相容你當下使用的 mvc/mvp 架構。
增加你的應用的可測試性。
配合一個綁定機制效果最好。
mvvm模式和mvc模式一樣，主要目的是分離視圖（view）和模型（model），有幾大優點:
1. 低耦合。view可以獨立于model變化和修改，一個viewmodel可以綁定到不同的”view”上，當view變化的時候model可以不變，當model變化的時候view也可以不變。
2. 可重用性。你可以把一些視圖邏輯放在一個viewmodel裡面，讓很多view重用這段視圖邏輯。
3. 獨立開發。開發人員可以專注于業務邏輯和資料的開發（viewmodel），設計人員可以專注于頁面設計，生成xml代碼。
4. 可測試。界面素來是比較難于測試的，而現在測試可以針對viewmodel來寫。
任何的項目架構，都是為項目服務的。沒有絕對的好壞之分，隻有更合适的選擇。在項目進展的不同階段，做出最合适的調整，才是是更适合團隊項目發展的架構。項目設計者要謹記，任何的項目設計，都是要圍繞項目發展階段，團隊成員規模，和團隊整體能力而定的。切莫為了設計而設計，為了架構而架構。快速，高效的配合整個團隊進展項目，才是最合适的架構。才是一個程式員為成一個leader，成為一個架構師的必經之路。
轉載，請說明來源：http://blog.csdn.net/hudan2714/article/details/50990359