1、MVC框架
MVC全名是Model View Controller,是模型(model)-視圖(view)-控制器(controller)的縮寫,一種軟件設計典範,用一種業務邏輯、數據、界面顯示分離的方法組織代碼,將業務邏輯聚集到一個部件裏面,在改進和個性化定製界面及用戶交互的同時,不需要重新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。
簡單來說就是通過controller的控制去操作model層的數據,並且返回給view層展示,當用戶出發事件的時候,view層會發送指令到controller層,接着controller去通知model層更新數據,model層更新完數據以後直接顯示在view層上,這就是MVC的工作原理。
如下圖:
那具體到Android上是怎麼樣一個情況呢?
大家都知道一個Android工程有什麼對吧,有java的class文件,有res文件夾,裏面是各種資源,還有類似manifest文件等等。對於原生的Android項目來說,layout.xml裏面的xml文件就對應於MVC的view層,裏面都是一些view的佈局代碼,而各種java bean,還有一些類似repository類就對應於model層,至於controller層嘛,當然就是各種activity咯。大家可以試着套用我上面說的MVC的工作原理是理解。比如你的界面有一個按鈕,按下這個按鈕去網絡上下載一個文件,這個按鈕是view層的,是使用xml來寫的,而那些和網絡連接相關的代碼寫在其他類裏,比如你可以寫一個專門的networkHelper類,這個就是model層,那怎麼連接這兩層呢?是通過button.setOnClickListener()這個函數,這個函數就寫在了activity中,對應於controller層。是不是很清晰。
1.1 MVC模式的角色說明
角色 | 描述 | Android中的對象 |
---|---|---|
Model(模型) | 負責提供數據模型以及處理,也負責在數據更改的時候提醒視圖。(例如對數據庫的操作,對網絡數據的操作以及業務中的計算等操作應該放在該層) | Model類 |
View(視圖) | 數據的可視化,也就是讓用戶看到數據。 | xml文件,自定義View類,自定義Layout類 |
Controller(控制器) | 負責處理用戶交互。 | Activity,Fragment |
1.2 MVC的優缺點
- 優點
- 邏輯分離,專事專辦,視圖層和業務層分離,一定程度上降低了代碼間的耦合性。
- 代碼的重用性高(同樣的方法,如果有其他的地方需要的話,可以直接調用)。
- 缺點
- 中小型項目用起來太麻煩(項目小的話,用該框架反而會變的複雜化,比如代碼量,有時候一個函數就能搞定的,用該框架反而多此一舉)。
- VC層耦合性過高,這個是特定針對Android的,因爲在Android端,C層代表的是Activity/Fragment,這個是我們主要的用戶交互界面,它總是會不可避免的染上一堆視圖的邏輯(比如Activity/Fragment切換,顯示Dialog,綁定控件)。這種情況下C層並沒有完全的C,而加入了一部分V層的操作。
- 隨着界面及其邏輯的複雜度不斷提升,Activity類的職責不斷增加,以致變得龐大臃腫。
- M層的邏輯太多,M層不僅要負責數據的生成,還要負責數據的加工,更要負責視圖的提醒這種情況下M層的任務太重且類型太多,就不易於維護。
2、MVP框架
全稱:Model-View-Presenter ;MVP 是從經典的模式MVC演變而來,它們的基本思想有相通的地方Controller/Presenter負責邏輯的處理,Model提供數據,View負責顯示。
從圖中就可以看出,最明顯的差別就是view層和model層不再相互可知,完全的解耦,取而代之的presenter層充當了橋樑的作用,用於操作view層發出的事件傳遞到presenter層中,presenter層去操作model層,並且將數據返回給view層,整個過程中view層和model層完全沒有聯繫。看到這裏大家可能會問,雖然view層和model層解耦了,但是view層和presenter層不是耦合在一起了嗎?其實不是的,對於view層和presenter層的通信,我們是可以通過接口實現的,具體的意思就是說我們的activity,fragment可以去實現實現定義好的接口,而在對應的presenter中通過接口調用方法。不僅如此,我們還可以編寫測試用的View,模擬用戶的各種操作,從而實現對Presenter的測試。這就解決了MVC模式中測試,維護難的問題。
1.1 MVP模式的角色說明
角色 | 描述 | Android中的對象 |
---|---|---|
Model(模型) | 主要做一些數據處理, 網路請求。Presenter 需要通過 Model 層存取、獲取數據,Model是封裝了數據庫 Dao 層或者網絡獲取數據的角色,或者兩種數據獲取方式的集合。 | Model類(數據庫,網絡數據) |
View(視圖) | 用戶界面,Activity、Fragment 或者某個 View 控件,含有一個 Presenter 成員變量,通常 View 層需要實現一個邏輯接口,將 View 上的操作通過會轉交給 Presenter 進行實現,最後 Presenter 調用 View 邏輯接口將結果返回給 View 元素。 | Activity,Fragment |
Presenter(協調者) | 交互中間人,核心邏輯,處理 View 的業務邏輯,溝通 View 和 Model 的橋樑,Presenter 持有的 View、Model 引用都是抽象,它從 Model 層檢索數據後返回給 View 層,使得 View 和 Model 沒有耦合,也將業務邏輯從 View 層抽取出來,經常會執行耗時操作。 | Presenter類/Controller類 |
1.2 MVP的優缺點
- 優點
- 複雜的邏輯處理放在presenter進行處理,減少了activity的臃腫。
- M層與V層完全分離,修改V層不會影響M層,降低了耦合性。
- 可以將一個Presenter用於多個視圖,而不需要改變Presenter的邏輯。
- P層與V層的交互是通過接口來進行的,便於單元測試。
- 缺點
- 由於對視圖的渲染放在了Presenter中,所以視圖和Presenter的交互會過於頻繁,視圖需要改變,一般presenter也需要跟着改變。
3、MVVM框架
簡介:MVVM是Model-View-ViewModel的簡寫。VM是ViewModel的縮寫,VM可以理解爲View的數據模型和Presenter的合體,ViewModel和View之間的交互通過data binding完成。它本質上就是MVP 的改進版。MVVM 就是將其中的View 的狀態和行爲抽象化,讓我們將視圖 UI 和業務邏輯分開。當然這些事 ViewModel 已經幫我們做了,它可以取出 Model 的數據同時幫忙處理 View 中由於需要展示內容而涉及的業務邏輯。微軟的WPF帶來了新的技術體驗,如Silverlight、音頻、視頻、3D、動畫……,這導致了軟件UI層更加細節化、可定製化。同時,在技術層面,WPF也帶來了 諸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM(Model-View-ViewModel)框架的由來便是MVP(Model-View-Presenter)模式與WPF結合的應用方式時發展演變過來的一種新型架構框架。它立足於原有MVP框架並且把WPF的新特性糅合進去,以應對客戶日益複雜的需求變化。
1.1 MVVM模式的角色說明
角色 | 描述 | Android中的對象 |
---|---|---|
Model(模型) | 負責提供數據模型。 | Model類 |
View(視圖) | 數據的可視化,也就是讓用戶看到數據。 | 主要是Activity,Fragment |
ViewModel | 負責處理用戶交互和數據加工。 | ViewModel類 |
1.2 MVVM的優缺點
- 優點
低耦合
。視圖(View)可以獨立於Model變化和修改,一個ViewModel可以綁定到不同的"View"上,當View變化的時候Model可以不變,當Model變化的時候View也可以不變。
Data Binding可以實現雙向的交互,使得視圖和控制層之間的耦合程度進一步降低,分離更爲徹底,同時減輕了Activity的壓力。
可重用性
。你可以把一些視圖邏輯放在一個ViewModel裏面,讓很多view重用這段視圖邏輯。
獨立開發
。開發人員可以專注於業務邏輯和數據的開發(ViewModel),設計人員可以專注於頁面設計,使用Expression Blend可以很容易設計界面並生成xml代碼。
可測試
。界面素來是比較難於測試的,而現在測試可以針對ViewModel來寫。
4、總結
MVP與MVC區別:
作爲一種新的模式,MVP與MVC有着一個重大的區別:
- 在MVP中View並不直接使用Model,它們之間的通信是通過Presenter(MVC中的Controller)來進行的,所有的交互都發生在Presenter內部,而在MVC中View會直接從Model中讀取數據而不是通過Controller。
- 在MVC裏,View是可以直接訪問Model的!從而,View裏會包含Model信息,不可避免的還要包括一些業務邏輯。 在MVC模型裏,更關注的Model的改變,而同時有多個對Model的不同顯示,即View。所以,在MVC模型裏,Model不依賴於View,但是View是依賴於Model的。不僅如此,因爲有一些業務邏輯在View裏實現了,導致要更改View也是比較困難的,至少那些業務邏輯是無法重用的。 雖然 MVC 中的 View 的確“可以”訪問 Model,但是我們不建議在 View 中依賴Model,而是要求儘可能把所有業務邏輯都放在 Controller 中處理,而 View 只和 Controller 交互。
MVVM與MVP區別:
mvvm模式將Presener改名爲View Model,基本上與MVP模式完全一致,唯一的區別是,它採用雙向綁定(data-binding): View的 變動,自動反映在ViewModel,反之亦然。這樣開發者就不用處理接收事件和View更新的工作,框架已經幫你做好了。