iOS開發--MVVM-R架構之美

MVVM-R

開發軟件就像搭建房子,一個好的架構設計,決定著房子搭建的速度、質量和高度。對于移動端開發來說,有常見的MVCMVPMVVMVIPER等架構模式,這些架構有各自的優缺點,如何尋找合適的架構,這得結合當前的項目情況和期望。筆者這邊在綜合考慮各種因素之后,決定使用MVVM-R作為項目的開發架構。下面做下思考的過程。

一個好的架構應該具有的特征:

  • 職責單一
  • 可測性
  • 易用性

Apple 的 MVC

理想狀態

MVC.png
  • Models(模型)? - 數據層,提供對應的數據結構。比如 Person 類。
  • Views(視圖) - 展示層(GUI)。對于 iOS 來說所有以 UI 開頭的類基本都屬于這層。
  • Controller 控制器 - 它是 ModelView 之間的膠水或者說是中間人。一般來說,當用戶對 View 有操作時它負責去修改相應 Model;當 Model 的值發生變化時它負責去更新對應 View

現實情況

Apple 的 MVC看上去挺美好的,View 和 Model 之間相互獨立的,只是通過 Controller 來相互聯系。但是在實際的開發中,往往為了方便,views中還是會引入models進行賦值操作,而且Controller中會寫網絡數據操作、業務邏輯操作和交互等等代碼,顯得特別冗腫,不易擴展和后期維護。
對應說需要集成單元測試的來說,因為每個模塊耦合太嚴重基本無法進行。

總結:

  • 職責劃分:理想狀態下,View 和 Model 確實是實現了分離,但是 View 和 Controller 耦合的太厲害
  • 可測性:因為劃分的不夠清楚,所以能測的基本就只有 Model 而已
  • 易用:相較于其他模式,它的代碼量最少。而且基本上每個人都很熟悉它,即便是沒太多經驗的開發者也能維護。

如果是對于小項目,只追求開發速度,則MVC可能是較佳的選擇。

MVP - 保證了職責劃分的(promises delivered) Cocoa MVC

MVP.png
  • Models(模型)? - 數據層,負責處理數據的數據接口層,包括網絡請求和數據處理等。
  • View/Controller - 展示層和交互層。MVP里面的 View 和 Controller 是耦合緊密的,給Presenter提供視圖設置和交互的方法,沒有直接拿model進行賦值好操作,保持了很好的獨立性。
  • Presenter - 它完全不關注 ViewController 的生命周期,里面基本沒什么布局相關的代碼,它的職責只是通過數據和狀態來調用View層提供的方法來更新UI。

MVP 架構擁有三個真正獨立的分層,V層通過提供方法,讓P層調用和賦值,M層只負責數據提供,具有很好的可測試性,但相對于MVC來說意味著巨大的代碼量。

總結:

  • 劃分: 我們把大部分的職責都分配到了 Presenter 和 Model 里面,而 View 基本上不需要做什么。
  • 可測性:簡直棒,我們可以通過 View 來測試大部分的業務邏輯。
  • 易用: MVP擁有清晰架構思路,但在代碼量上會相對做出犧牲。

MVP 架構在 iOS 中意味著極好的可測性和巨大的代碼量。

VIPER - 把搭建樂高積木的經驗應用到 iOS 應用的設計上

VIPER.png

VIPER的五層職責劃分:

  • Entity(實體):類似于MVC的Model,是一個純粹的數據結構對象。
  • Interactor(交互器):專門用來負責網絡請求和數據處理。
  • View/Controller(視圖):負責UI的布局和提供交互相關的方法,供Presenter調用。
  • Presenter(展示器):負責處理包括調用Interactor進行網絡請求,根據狀態刷新UI界面,根據用戶交互處理相關的業務邏輯等。
  • Router(路由): 主要負責 VIPER 模塊之間的轉場和銜接。

總結:

  • 劃分:毫無疑問的,VIPER 在職責劃分方面是做的最好的。
  • 可測性:理所當然的,職責劃分的越好,測試起來就越容易。
  • 易用:不難想象,上面兩點好處都是用維護性的代價換來的。一個小小的任務,可能就需要你為各種類寫大量的接口。

如果你的項目較大或未來會很大,VIPER可能是更好的選擇。

MVVM - 是 MV(X) 系列架構里面最新興的,也是最出色的

MVVM.png
  • Models(模型)? - 數據模型,用來存儲數據。
  • View/Controller(視圖) - 視圖界面,用來展示UI界面和響應用戶交互。
  • ViewModel - 鏈接View和Model的橋梁,處理業務邏輯,更新Model的同時刷新View。

ViewModel可以看做是MVC中對C層的一種優化和升級,把Controller的數據和邏輯處理部分從中抽離出來,用一個專門的對象去管理,這個對象就是ViewModel,是Model和Controller之間的一座橋梁。當MVVM結合綁定模式之后(使用全量級的函數式響應編程框架,比如 ReactiveCocoaRxSwift),它變得越來越受開發者的喜愛,不單單解耦了每個模塊,而且還精簡了代碼,給后期的維護和寫單元測試提供了方便。

總結:

  • 劃分: MVVM 框架里面的 View 比 MVP 里面負責的事情要更多一些。因為前者是通過 ViewModel 的數據綁定來更新自身狀態的,而后者只是把所有的事件統統交給 Presenter 去處理就完了,自己本身并不負責更新。
  • 可測性:因為 ViewModel 對 View 是一無所知的,這樣我們對它的測試就變得很簡單。View 應該也是能夠被測試的,但是可能因為它對 UIKit 的依賴,你會直接略過它。
  • 易用:MVVM的代碼量基本跟 MVP 持平,但是在實際的應用當中 MVVM 會更簡潔一些。因為在 MVP 下你必須要把 View 的所有事件都交給 Presenter 去處理,而且需要手動的去更新 View 的狀態;而在 MVVM 下,你只需要用綁定就可以解決。

MVVM在結合函數式響應編程之后,會變得更加有魅力,但是也會相應的給開發者提出更多的挑戰,例如:函數式響應編程在調試方明的問題和對TableView中視圖和模型之間如何優雅的綁定問題等等,不過相信這些都不是問題。

MVVM-R架構之美

在了解完MVCMVPMVVMVIPER架構之后,這里結合項目的需要,覺得MVVM會更適合現有的項目。所以在此基礎上對MVVM進行了一些小擴展,使各個模塊更加的獨立可測試,也就是我們一開始看到的這張架構圖。

MVVM-R

MVVM-R思想:

  • V:負責視圖布局和提供自身需要的數據模型(通過protocol實現),View自身的交互事件,通過delegate代理出去;
  • C:管理生命周期和事件交互;
  • M:只提供數據結構,遵守了View提供的協議;
  • VM:網絡請求和業務邏輯處理,界面的顯示完全由VM配置數據源決定;
  • R:處理模塊間的跳轉。

好處:

  • View層完全的獨立出來,不需要關心誰給它傳遞數據,誰來處理交互事件;
  • View和Model層實現了完全的解耦;
  • ViewModel通過配置數據模型,決定視圖的展示。

結合綁定:

這里寫了一份MVVM-R架構的Demo,僅供交流學習:
MVVM-R架構之美

感謝:
淺談 MVC、MVP 和 MVVM 架構模式
iOS 架構模式 - 簡述 MVC, MVP, MVVM 和 VIPER
不談框架,談細節

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容