MVVM-R

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

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

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

Apple 的 MVC

理想狀態

MVC.png

• Models（模型）? - 數據層，提供對應的數據結構。比如 Person 類。
• Views（視圖） - 展示層(GUI)。對于 iOS 來說所有以 UI 開頭的類基本都屬于這層。
• Controller 控制器 - 它是 Model 和 View 之間的膠水或者說是中間人。一般來說，當用戶對 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結合綁定模式之后（使用全量級的函數式響應編程框架,比如 ReactiveCocoa、RxSwift 等），它變得越來越受開發者的喜愛，不單單解耦了每個模塊，而且還精簡了代碼，給后期的維護和寫單元測試提供了方便。

總結：

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

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

MVVM-R架構之美

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

MVVM-R

MVVM-R思想：

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

好處：

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

結合綁定：

• 選一個基于 KVO 的綁定庫，比如 RZDataBinding 或者 SwiftBond。
• 使用全量級的 函數式響應編程 框架,比如 ReactiveCocoa、RxSwift 或者 PromiseKit。

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

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