我想提供一個具體的例子來說明它比MVC更有競爭力，更具意義。

  最近我創(chuàng)建的一個App中，我們有一堆數(shù)據(jù)，支持下拉刷新,每一個元素點擊之后會推出詳情頁面,視圖控制器有很多業(yè)務(wù)邏輯,非常標(biāo)準(zhǔn)的東西。然而，這一堆數(shù)據(jù)彼此之間來路是不一樣的，有的是主API入口的數(shù)據(jù)結(jié)果，有的是它們的搜索結(jié)果，有的是App在編譯時就決定的靜態(tài)元素。

  使用MVC的話，我想到了兩種方法來解決：

1. 在臃腫的視圖控制器中創(chuàng)建一個類處理顯示,并管理所有的數(shù)據(jù)內(nèi)容
2. 毫無疑問，另一種方法就是子類化一個視圖控制器的抽象基類來包含所有內(nèi)容的通用邏輯。

  這是過去我所采用的方式，但這方式很難重構(gòu)，比方說：有些所有類型的通用內(nèi)容變得只對部分類型有效時。這同樣也能被稱為是一種黑客攻擊，因為Objective-C不支持抽象類。

  我采用的方法是使用符合該視圖控制器所依賴的協(xié)議的不同的視圖模型。通過將定制的業(yè)務(wù)邏輯放置于視圖模型中，我避免了視圖控制器的臃腫化，視圖控制器僅需要根據(jù)視圖模型的協(xié)議來知道如何顯示即可。 MVVM是子類化視圖控制器的一個很好的選擇。

  另外，如果你有多平臺需求(比如說：iOS & OSX)，他們可以共用一套視圖模型，因為他們不牽扯到視圖本身的邏輯。你甚至可以走得更遠(yuǎn)，用另外的語言來生成視圖模型，然后生成指定的語言的視圖模型對象比如：Objective-C、C#、Ruby、Java或者其他你需要的任何語言。瘋狂吧這玩意~

  最后，我們并沒有真正地涉及到RACCommand的使用。我將利用Justin Spahr-Summers的說法在MVVM的范疇來解釋它。

1. 控制(事件)與它交互
2. 一個屬于視圖模型的命令被執(zhí)行
3. 視圖模型的邏輯被運行(運行的是命令初始化時的signalBlock)
4. 視圖模型通過ReactiveCocoa來間接通知視圖。在我們的例程中，視圖會被更新。

  再一次強調(diào)Github倉庫包含了我們在本書中沒有能夠涉及的，關(guān)于RACCommand的，使用的詳細(xì)信息。去看一看吧！

  MVVM效果很好，與ReactiveCocoa結(jié)合起來使用更好。一下子掌握它太難了，你不妨從小處著手，先在一個視圖控制器中使用，看看你到底能有多適合它，然后再在你的下一個項目中嘗試使用它吧，你會看到它如何徹底簡化你的視圖控制器的復(fù)雜度。