Android 架構設計實現之MVC、MVP及MVVM詳解

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更新的工作,框架已經幫你做好了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章