我於 2011 年在 500px 找到本身的第一份 iOS 開發工做。雖然我已經在大學裏作了好幾年 iOS 外包開發,但這纔是個人一個真正的 iOS 開發工做。我被做爲惟一的 iOS 開發者被招聘去實現擁有漂亮設計的 iPad 應用。在短短七週裏,咱們就發佈了 1.0 並持續迭代,添加了更多特性,但從本質上,代碼庫也變得更加複雜了。編程
有時我感受就像我不知道在作什麼。雖然我知道本身的設計模式——就像任何好的編程人員那樣 —— 但我太接近我在作的產品以致於不能客觀地衡量個人架構決策的有效性。當隊伍中來了另一位開發者時,我意識到咱們陷入困境了。設計模式
從沒聽過 MVC ?有人稱之爲 Massive View Controller(重量級視圖控制器),這就是咱們那時候的感受。我不打算介紹使人汗顏的細節,但說實在的,若是我不得再也不次重來一次,我絕對會作出不一樣的決策。架構
我會修改一個關鍵架構,並將其帶入我從那時起就在開發的各類應用,即便用一種叫作 Model-View-ViewModel 的架構替換 Model-View-Controller。框架
因此,MVVM 究竟是什麼?與其專一於說明 MVVM 的來歷,不如讓咱們看一個典型的 iOS 是如何構建的,並從那裏瞭解 MVVM:
咱們看到的是一個典型的 MVC 設置。Model 呈現數據,View 呈現用戶界面,而 View Controller 調節它二者之間的交互。Cool!mvvm
稍微考慮一下,雖然 View 和 View Controller 是技術上不一樣的組件,但它們幾乎老是手牽手在一塊兒,成對的。你何時看到一個 View 可以與不一樣 View Controller 配對?或者反過來?因此,爲何不正規化它們的鏈接呢?
這更準確地描述了你可能已經編寫的 MVC 代碼。但它並無作太多事情來解決 iOS 應用中日益增加的重量級視圖控制器的問題。在典型的 MVC 應用裏,許多邏輯被放在 View Controller 裏。它們中的一些確實屬於 View Controller,但更多的是所謂的「表示邏輯(presentation logic)」,以 MVVM 屬術語來講,就是那些將 Model 數據轉換爲 View 能夠呈現的東西的事情,例如將一個 NSDate 轉換爲一個格式化過的 NSString。post
咱們的圖解裏缺乏某些東西,那些使咱們能夠把全部表示邏輯放進去的東西。咱們打算將其稱爲 「View Model」 —— 它位於 View/Controller 與 Model 之間:
看起好多了!這個圖解準確地描述了什麼是 MVVM:一個 MVC 的加強版,咱們正式鏈接了視圖和控制器,並將表示邏輯從 Controller 移出放到一個新的對象裏,即 View Model。MVVM 聽起來很複雜,但它本質上就是一個精心優化的 MVC 架構,而 MVC 你早已熟悉。單元測試
如今咱們知道了什麼是 MVVM,但爲何咱們會想要去使用它呢?在 iOS 上使用 MVVM 的動機,對我來講,不管如何,就是它能減小 View Controller 的複雜性並使得表示邏輯更易於測試。經過一些例子,咱們將看到它如何達到這些目標。學習
此處有三個重點是我但願你看完本文能帶走的:測試
MVVM 能夠兼容你當下使用的 MVC 架構。
MVVM 增長你的應用的可測試性。
MVVM 配合一個綁定機制效果最好。
如咱們以前所見,MVVM 基本上就是 MVC 的改進版,因此很容易就能看到它如何被整合到現有使用典型 MVC 架構的應用中。讓咱們看一個簡單的 Person Model 以及相應的 View Controller:優化
1 |
@interface Person : NSObject |
Cool!如今咱們假設咱們有一個 PersonViewController ,在 viewDidLoad 裏,只須要基於它的 model 屬性設置一些 Label 便可。
1 |
- (void)viewDidLoad { |
這全都直截了當,標準的 MVC。如今來看看咱們如何用一個 View Model 來加強它。
1 |
@interface PersonViewModel : NSObject |
咱們的 View Model 的實現大概以下:
1 |
@implementation PersonViewModel |
Cool!咱們已經將 viewDidLoad 中的表示邏輯放入咱們的 View Model 裏了。此時,咱們新的 viewDidLoad 就會很是輕量:
1 |
- (void)viewDidLoad { |
因此,如你所見,並無對咱們的 MVC 架構作太多改變。仍是一樣的代碼,只不過移動了位置。它與 MVC 兼容,帶來更輕量的 View Controllers。
可測試,嗯?是怎樣?好吧,View Controller 是出了名的難以測試,由於它們作了太多事情。在 MVVM 裏,咱們試着儘量多的將代碼移入 View Model 裏。測試 View Controller 就變得容易多了,由於它們再也不作一大堆事情,而且 View Model 也很是易於測試。讓咱們來看看:
1 |
SpecBegin(Person) |
若是咱們沒有將這個邏輯移入 View Model,咱們將不得不實例化一個完整的 View Controller 以及伴隨的 View,而後去比較咱們 View 中 Lable 的值。這樣作不僅是會變成一個麻煩的間接層,並且它只表明了一個十分脆弱的測試。如今,咱們能夠按意願自由地修改視圖層級而沒必要擔憂破壞咱們的單元測試。使用 MVVM 帶來的對於測試的好處很是清晰,甚至從這個簡單的例子來看也可見一斑,而在有更復雜的表示邏輯的狀況下,這個好處會更加明顯。
注意到在這個簡單的例子中, Model 是不可變的,因此咱們能夠只在初始化的時候指定咱們 View Model 的屬性。對於可變 Model,咱們還須要使用一些綁定機制,這樣 View Model 就能在背後的 Model 改變時更新自身的屬性。此外,一旦 View Model 上的 Model 發生改變,那 View 的屬性也須要更新。Model 的改變應該級聯向下經過 View Model 進入 View。
在 OS X 上,咱們可使用 Cocoa 綁定,但在 iOS 上咱們並無這樣好的配置可用。咱們想到了 KVO(Key-Value Observation),並且它確實作了很偉大的工做。然而,對於一個簡單的綁定都須要很大的樣板代碼,更不用說有許多屬性須要綁定了。做爲替代,我我的喜歡使用 ReactiveCocoa,但 MVVM 並未強制咱們使用 ReactiveCocoa。MVVM 是一個偉大的典範,它自身獨立,只是在有一個良好的綁定框架時作得更好。
咱們覆蓋了很多內容:從普通的 MVC 派生出 MVVM,看它們是如何相兼容的範式,從一個可測試的例子觀察 MVVM,並看到 MVVM 在有一個配對的綁定機制時工做得更好。若是你有興趣學習更多關於 MVVM 的知識,你能夠看看這篇博客,它用更多細節解釋了 MVVM 的好處,或者這一篇關於咱們如何在最近的項目裏使用 MVVM 得到巨大的成功的文章。我一樣還有一個通過完整測試,基於 MVVM 的應用,叫作 C-41 ,它是開源的。