MVVM總結(jié)

  我想提供一個(gè)具體的例子來(lái)說(shuō)明它比MVC更有競(jìng)爭(zhēng)力，更具意義。

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

  使用MVC的話，我想到了兩種方法來(lái)解決：

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

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

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

  另外，如果你有多平臺(tái)需求(比如說(shuō)：iOS & OSX)，他們可以共用一套視圖模型，因?yàn)樗麄儾粻砍兜揭晥D本身的邏輯。你甚至可以走得更遠(yuǎn)，用另外的語(yǔ)言來(lái)生成視圖模型，然后生成指定的語(yǔ)言的視圖模型對(duì)象比如：Objective-C、C#、Ruby、Java或者其他你需要的任何語(yǔ)言。瘋狂吧這玩意~

  最后，我們并沒(méi)有真正地涉及到RACCommand的使用。我將利用Justin Spahr-Summers的說(shuō)法在MVVM的范疇來(lái)解釋它。

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

  再一次強(qiáng)調(diào)Github倉(cāng)庫(kù)包含了我們?cè)诒緯?shū)中沒(méi)有能夠涉及的，關(guān)于RACCommand的，使用的詳細(xì)信息。去看一看吧！

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