【框架篇】mvc、mvp、mvvm使用關系總結
MVC
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
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數據
MVP的優勢
- Model與View完全分離,修改互不影響
- 更高效地使用,因為所有的邏輯交互都發生在一個地方—Presenter內部
- 一個Preseter可用於多個View,而不需要改變Presenter的邏輯(因為View的變化總是比Model的變化頻繁)。
- 更便於測試。把邏輯放在Presenter中,就可以脫離用戶接口來測試邏輯(單元測試)
方式
各部分之間都是雙向通信
結構實現
View :使用 Composite模式
View和Presenter:使用 Mediator模式
Model和Presenter:使用 Command模式同步信息
MVC和MVP區別
MVP與MVC最大的一個區別就是:Model與View層之間倒底該不該通信(甚至雙向通信)
MVC和MVP關系
MVP:是MVC模式的變種。
項目開發中,UI是容易變化的,且是多樣的,一樣的數據會有N種顯示方式;業務邏輯也是比較容易變化的。為了使得應用具有較大的彈性,我們期望將UI、邏輯(UI的邏輯和業務邏輯)和數據隔離開來,而MVP是一個很好的選擇。
Presenter代替了Controller,它比Controller擔當更多的任務,也更加復雜。Presenter處理事件,執行相應的邏輯,這些邏輯映射到Model操作Model。那些處理UI如何工作的代碼基本上都位於Presenter。
MVC中的Model和View使用Observer模式進行溝通;MPV中的Presenter和View則使用Mediator模式進行通信;Presenter操作Model則使用Command模式來進行。基本設計和MVC相同:Model存儲數據,View對Model的表現,Presenter協調兩者之間的通信。在 MVP 中 View 接收到事件,然後會將它們傳遞到 Presenter, 如何具體處理這些事件,將由Presenter來完成。
如果要實現的UI比較復雜,而且相關的顯示邏輯還跟Model有關系,就可以在View和 Presenter之間放置一個Adapter。由這個 Adapter來訪問Model和View,避免兩者之間的關聯。而同時,因為Adapter實現了View的接口,從而可以保證與Presenter之 間接口的不變。這樣就可以保證View和Presenter之間接口的簡潔,又不失去UI的靈活性。
使用
MVP的實現會根據View的實現而有一些不同,一部分傾向於在View中放置簡單的邏輯,在Presenter放置復雜的邏輯;另一部分傾向於在presenter中放置全部的邏輯。這兩種分別被稱為:Passive View和Superivising Controller。
MVVM
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 接收用戶交互請求
- View 將請求轉交給ViewModel
- ViewModel 操作Model數據更新
- Model 更新完數據,通知ViewModel數據發生變化
- ViewModel 更新View數據
方式
雙向綁定。View/Model的變動,自動反映在 ViewModel,反之亦然。
使用
- 可以兼容你當下使用的 MVC/MVP 框架。
- 增加你的應用的可測試性。
- 配合一個綁定機制效果最好。
MVVM優點
MVVM模式和MVC模式一樣,主要目的是分離視圖(View)和模型(Model),有幾大優點:
1. 低耦合。View可以獨立於Model變化和修改,一個ViewModel可以綁定到不同的”View”上,當View變化的時候Model可以不變,當Model變化的時候View也可以不變。
2. 可重用性。你可以把一些視圖邏輯放在一個ViewModel裏面,讓很多view重用這段視圖邏輯。
3. 獨立開發。開發人員可以專註於業務邏輯和數據的開發(ViewModel),設計人員可以專註於頁面設計,生成xml代碼。
4. 可測試。界面素來是比較難於測試的,而現在測試可以針對ViewModel來寫。
mvc,mvp,mvvm三者演化
說明
任何的項目框架,都是為項目服務的。沒有絕對的好壞之分,只有更合適的選擇。在項目進展的不同階段,做出最合適的調整,才是是更適合團隊項目發展的框架。項目設計者要謹記,任何的項目設計,都是要圍繞項目發展階段,團隊成員規模,和團隊整體能力而定的。切莫為了設計而設計,為了框架而框架。快速,高效的配合整個團隊進展項目,才是最合適的架構。才是一個程序員為成一個leader,成為一個架構師的必經之路。
轉載,請說明來源:http://blog.csdn.net/hudan2714/article/details/50990359
【框架篇】mvc、mvp、mvvm使用關系總結