MVC全名是Model View
Controller察署，是模型(model)－視圖(view)－控制器(controller)的縮寫闷游，一種軟件設(shè)計典范，用一種業(yè)務(wù)邏輯贴汪、數(shù)據(jù)脐往、界面顯示分離的方法組織代碼，將業(yè)務(wù)邏輯聚集到一個部件里面扳埂，在改進(jìn)和個性化定制界面及用戶交互的同時业簿，不需要重新編寫業(yè)務(wù)邏輯。MVC被獨(dú)特的發(fā)展起來用于映射傳統(tǒng)的輸入阳懂、處理和輸出功能在一個邏輯的圖形化用戶界面的結(jié)構(gòu)中梅尤。
數(shù)據(jù)關(guān)系
View 接受用戶交互請求?
View 將請求轉(zhuǎn)交給Controller
Controller 操作Model進(jìn)行數(shù)據(jù)更新
數(shù)據(jù)更新之后，Model通知View更新數(shù)據(jù)變化
View 更新變化數(shù)據(jù)
方式
所有方式都是單向通信
結(jié)構(gòu)實(shí)現(xiàn)
View ：使用? Composite模式
View和Controller：使用 Strategy模式
Model和 View：使用 Observer模式同步信息
使用
MVC中的View是可以直接訪問Model的岩调！從而巷燥，View里會包含Model信息，不可避免的還要包括一些業(yè)務(wù)邏輯号枕。在MVC模型里缰揪，更關(guān)注的Model的不變，而同時有多個對Model的不同顯示葱淳，及View钝腺。所以，在MVC模型里赞厕，Model不依賴于View拍屑，但是
View是依賴于Model的。不僅如此坑傅，因為有一些業(yè)務(wù)邏輯在View里實(shí)現(xiàn)了僵驰，導(dǎo)致要更改View也是比較困難的，至少那些業(yè)務(wù)邏輯是無法重用的。
mvp的全稱為Model-View-Presenter蒜茴，Model提供數(shù)據(jù)星爪，View負(fù)責(zé)顯示，Controller/Presenter負(fù)責(zé)邏輯的處理粉私。MVP與MVC有著一個重大的區(qū)別：在MVP中View并不直接使用Model顽腾，它們之間的通信是通過Presenter
(MVC中的Controller)來進(jìn)行的，所有的交互都發(fā)生在Presenter內(nèi)部诺核，而在MVC中View會直接從Model中讀取數(shù)據(jù)而不是通過
Controller抄肖。
數(shù)據(jù)關(guān)系
View 接收用戶交互請求
View 將請求轉(zhuǎn)交給 Presenter
Presenter 操作Model進(jìn)行數(shù)據(jù)更新
Model 通知Presenter數(shù)據(jù)發(fā)生變化
Presenter 更新View數(shù)據(jù)
MVP的優(yōu)勢
Model與View完全分離，修改互不影響
更高效地使用窖杀，因為所有的邏輯交互都發(fā)生在一個地方—Presenter內(nèi)部
一個Preseter可用于多個View漓摩，而不需要改變Presenter的邏輯（因為View的變化總是比Model的變化頻繁）。
更便于測試入客。把邏輯放在Presenter中管毙，就可以脫離用戶接口來測試邏輯（單元測試）
方式
各部分之間都是雙向通信
結(jié)構(gòu)實(shí)現(xiàn)
View ：使用? Composite模式
View和Presenter：使用 Mediator模式
Model和Presenter：使用 Command模式同步信息
MVC和MVP區(qū)別
MVP與MVC最大的一個區(qū)別就是：Model與View層之間倒底該不該通信（甚至雙向通信）
MVC和MVP關(guān)系
MVP：是MVC模式的變種。
項目開發(fā)中桌硫，UI是容易變化的夭咬，且是多樣的，一樣的數(shù)據(jù)會有N種顯示方式铆隘；業(yè)務(wù)邏輯也是比較容易變化的卓舵。為了使得應(yīng)用具有較大的彈性，我們期望將UI膀钠、邏輯（UI的邏輯和業(yè)務(wù)邏輯）和數(shù)據(jù)隔離開來边器，而MVP是一個很好的選擇。
Presenter代替了Controller托修，它比Controller擔(dān)當(dāng)更多的任務(wù)忘巧，也更加復(fù)雜。Presenter處理事件睦刃，執(zhí)行相應(yīng)的邏輯砚嘴，這些邏輯映射到Model操作Model。那些處理UI如何工作的代碼基本上都位于Presenter涩拙。
MVC中的Model和View使用Observer模式進(jìn)行溝通际长；MPV中的Presenter和View則使用Mediator模式進(jìn)行通信；Presenter操作Model則使用Command模式來進(jìn)行兴泥」び基本設(shè)計和MVC相同：Model存儲數(shù)據(jù)，View對Model的表現(xiàn)搓彻，Presenter協(xié)調(diào)兩者之間的通信如绸。在 MVP 中 View 接收到事件嘱朽，然后會將它們傳遞到 Presenter, 如何具體處理這些事件，將由Presenter來完成怔接。
如果要實(shí)現(xiàn)的UI比較復(fù)雜搪泳，而且相關(guān)的顯示邏輯還跟Model有關(guān)系，就可以在View和 Presenter之間放置一個Adapter扼脐。由這個 Adapter來訪問Model和View岸军，避免兩者之間的關(guān)聯(lián)。而同時瓦侮，因為Adapter實(shí)現(xiàn)了View的接口艰赞，從而可以保證與Presenter之 間接口的不變。這樣就可以保證View和Presenter之間接口的簡潔肚吏，又不失去UI的靈活性方妖。
1
2
3
4
5
6
使用
MVP的實(shí)現(xiàn)會根據(jù)View的實(shí)現(xiàn)而有一些不同，一部分傾向于在View中放置簡單的邏輯须喂，在Presenter放置復(fù)雜的邏輯；另一部分傾向于在presenter中放置全部的邏輯趁蕊。這兩種分別被稱為：Passive
View和Superivising Controller坞生。
MVVM是Model-View-ViewModel的簡寫。微軟的WPF帶來了新的技術(shù)體驗掷伙，如Silverlight是己、音頻、視頻任柜、3D卒废、動畫……，這導(dǎo)致了軟件UI層更加細(xì)節(jié)化宙地、可定制化摔认。同時，在技術(shù)層面宅粥，WPF也帶來了
諸如Binding参袱、Dependency Property、Routed
Events秽梅、Command抹蚀、DataTemplate、ControlTemplate等新特性企垦。MVVM（Model-View-ViewModel）框架的由來便是MVP（Model-View-Presenter）模式與WPF結(jié)合的應(yīng)用方式時發(fā)展演變過來的一種新型架構(gòu)框架环壤。它立足于原有MVP框架并且把WPF的新特性糅合進(jìn)去，以應(yīng)對客戶日益復(fù)雜的需求變化钞诡。
數(shù)據(jù)關(guān)系
View 接收用戶交互請求
View 將請求轉(zhuǎn)交給ViewModel
ViewModel 操作Model數(shù)據(jù)更新
Model 更新完數(shù)據(jù)郑现，通知ViewModel數(shù)據(jù)發(fā)生變化
ViewModel 更新View數(shù)據(jù)
方式
雙向綁定湃崩。View/Model的變動，自動反映在 ViewModel懂酱，反之亦然竹习。
使用
可以兼容你當(dāng)下使用的 MVC/MVP 框架。
增加你的應(yīng)用的可測試性列牺。
配合一個綁定機(jī)制效果最好整陌。
MVVM優(yōu)點(diǎn)
MVVM模式和MVC模式一樣，主要目的是分離視圖（View）和模型（Model）瞎领，有幾大優(yōu)點(diǎn):
1. 低耦合泌辫。View可以獨(dú)立于Model變化和修改，一個ViewModel可以綁定到不同的”View”上九默，當(dāng)View變化的時候Model可以不變震放，當(dāng)Model變化的時候View也可以不變。
2. 可重用性驼修。你可以把一些視圖邏輯放在一個ViewModel里面殿遂，讓很多view重用這段視圖邏輯。
3. 獨(dú)立開發(fā)乙各。開發(fā)人員可以專注于業(yè)務(wù)邏輯和數(shù)據(jù)的開發(fā)（ViewModel）墨礁，設(shè)計人員可以專注于頁面設(shè)計，生成xml代碼耳峦。
4. 可測試恩静。界面素來是比較難于測試的，而現(xiàn)在測試可以針對ViewModel來寫蹲坷。
任何的項目框架驶乾，都是為項目服務(wù)的。沒有絕對的好壞之分循签，只有更合適的選擇级乐。在項目進(jìn)展的不同階段，做出最合適的調(diào)整县匠，才是是更適合團(tuán)隊項目發(fā)展的框架唇牧。項目設(shè)計者要謹(jǐn)記，任何的項目設(shè)計聚唐，都是要圍繞項目發(fā)展階段丐重，團(tuán)隊成員規(guī)模，和團(tuán)隊整體能力而定的杆查。切莫為了設(shè)計而設(shè)計扮惦，為了框架而框架∏阻耄快速崖蜜，高效的配合整個團(tuán)隊進(jìn)展項目浊仆，才是最合適的架構(gòu)。才是一個程序員為成一個leader豫领，成為一個架構(gòu)師的必經(jīng)之路抡柿。
轉(zhuǎn)載，請說明來源：http://blog.csdn.net/hudan2714/article/details/50990359
