[HMLY]7.iOS MVVM+RAC 從框架到實戰

1.MVVM淺析

MVC是構建iOS App的標準模式，是蘋果推薦的一個用來組織代碼的權威範式，市面上大部分App都是這樣構建的，具體組織模式不細說，iOS入門者都比較瞭解（雖然不必定能徹底去遵照），但其幾個不能避免的問題倒是很嚴重困擾開發者，好比厚重的ViewControlller、遺失的網絡邏輯（沒有屬於它的位置）、較差的可測試性等。所以也就會有維護性很強、耦合性很低的一種新架構MVVM（MVC引伸出的最新架構）的流行。

MVVM雖然來自微軟，可是不該該反對它，它正式規範了視圖和控制器緊耦合的性質，以下圖：

　　　　　　　　　　　　　　　　　　　　MVVM圖示

ViewModel:相比較於MVC新引入的視圖模型。是視圖顯示邏輯，驗證邏輯、網絡請求等存放的地方，惟一要注意的是，任何視圖自己的引用都不該該放在VM中，換句話說，就是VM中不要引入UIKit.h（對於Image這個，也有人將其看作數據來處理，這就看我的想法了，並不影響總體的架構）。

這樣，首先解決了VC臃腫的問題，將邏輯代碼、網絡請求等都寫入了VM中，而後又因爲VM中包含了全部的展現邏輯並且不會引用V，因此它是能夠經過編程充分測試的。

ReactiveCocoa是結合了函數式編程和響應式編程的框架，也能夠稱爲函數響應式編程（FRP）框架，強調一點，RAC雖然最大的優勢是提供了一個單一的，統一的方法去處理異步的行爲，包括delegate方法，blocks回調，target-action機制，notifications和KVO.可是不要簡單的只是單純的認爲他僅僅是減小代碼複雜度，更好的配合MVVM而已。

它最大的不同凡響是提供了一種新的寫代碼的思惟，因爲RAC將cocoa中KVO、UIKitEvent，delegate，selector等都增長了RAC支持，因此都不用去作不少跨函數的事。

若是全工程都使用RAC來實現，對已同一個業務邏輯終於能夠在同一塊代碼裏完成了，將UI事件，邏輯處理，文件或數據庫操做，異步網絡請求，UI結果顯示，這一大套通通用函數式編程的思路嵌套起來，進入頁面時搭建好這全部的關係，用戶點擊後妥妥的等待這一套聯繫一個個的定期望的邏輯和次序觸發，最後顯示給用戶。

3.本篇對二者的理解運用

在這次介紹中，會使用MVVM+RAC結合的方式，搞定一個添加上拉加載及下拉刷新的列表，因此更多的詮釋MVVM思想，而不是RAC的邏輯鏈式操做（這一點用登錄界面來寫更能體現），RAC在此扮演的更大一部分的角色是更好的解耦，減小代碼複雜度，使代碼井井有條、邏輯清晰便於維護升級。

2、框架部分

一、框架目錄詳解

首先介紹一下本框架的目錄結構，以下圖：

一、Frameworks

存放系統庫的虛擬文件夾，目前搭建框架的時候須要手動添加一個名稱爲Frameworks的虛擬文件夾，這樣你在Build phases中添加的系統庫會自動納入此文件夾，不會直接在外部顯示以致於打亂目錄結構。系統庫添加流程以下:

細心的會發現此目錄中有兩個相同的Frameworks，這是爲何？最上面的那個frameworks是在本身搭框架本身添加的，當時項目還很單純，問題是出在下面那個Pods Target上，添加它以後就會自動給你生成一個旭牛的frameworks的文件夾，那又該問了，爲啥不直接用下面那個呢？（二者之間並無衝突）

二、cocoapods

當開發iOS應用時，會常常用到不少第三方開源類庫，好比JSONKIT，AFNetworking等等。可能某個類庫又用到其餘類庫，因此要使用它，必須得下載其餘類庫，而其餘類庫又用到其餘類庫，」子子孫孫無窮盡也「，反正在早期程序員是會體驗到這種痛苦，心酸，手動一個個去下載所需類庫是十分麻煩的。

 

還有另一種狀況，項目中用到的類庫有更新，必須得從新下載新版本，從新加入到項目中，十分麻煩。

CocoaPods就是幫你解決上面問題的，話說這玩意應該是iOS最經常使用最有名的類庫管理工具了，做爲iOS程序員的咱們，掌握cocoapods的使用是必不可少的基本技能了。

 

三、AppDelegate

這個目錄下放的是APPDelegate.h(.m)文件，是整個應用的入口文件，因此單獨拿出來。一下子告訴你如何寫一個簡潔的AppDelegate，會在這個文件夾裏添加一些類，因此將其放入一個文件夾內仍是頗有必要的。

四、Class

工程主體類，平常大部分開發代碼均在這裏，又細分了好屢次級目錄。

通用類

·General:通用類（文件夾項目移植過程當中都不須要更改，就能直接使用的）

　　。Base:基類（整個框架的基類）

　　。Categories:公共擴展類（就是一些經常使用的類別，好比分享啊什麼的）

　　。Core:公共核心類（通常存放我的信息，接口API等）

　　。Models：公共Model(公用的一些數據模型)

　　。Views:公共View(封裝的一些經常使用的View)

工具類

　　·Helpers:工程的相關輔助類（好比相似數據請求、表單上傳、網絡監測等工具類）

宏定義類

　　·Macro : 宏定義類（就是整個應用會用到的宏定義）

　　　　。AppMacro.h app項目的相關宏定義

　　　　。NotificationMacro.h 通知相關的宏定義

　　　　。VendorMacro.h 第三方相關的宏定義

　　　　。UtilsMacro.h 爲簡化代碼的宏定義

　　　　。.......等等

APP具體模塊代碼類

　　·Sections ： 各模塊的文件夾（通常而言，咱們以人爲單位）

　　　　。LWSections 老王的文件夾

　　　　。......等等

每一個成員的文件夾下是其所負責模塊的文件夾，好比蒼老師負責PHP界面模塊，以下

·PHP ：模塊名，也能夠是首頁（HomePage）...等等

　　。ViewControllers 界面控制器存放處（這是文件夾名）

　　。ViewModels 打雜的(MVVM的核心、解耦合、處理邏輯等)

　　。View 界面相關View存放處（界面相關子View）

　　。Models 數據模型存放處（各類單純的數據模型，一點都不胖，是標準的瘦Model）

這就是標準的MVVM了

 

第三方類庫

　　·Vendors ： 第三方類庫/SDK,如UMeng、WeiboSDK、WeixinSDK等等。

剛纔的cocoapods確實管理着大部分的第三方庫，這裏創建第三方庫目錄緣由有兩個：其一，並非全部的你須要的第三方庫都支持pods，因此仍是須要手動添加一些類庫。其二，一些第三方庫雖然支持pods，可是須要咱們去更改甚至自定義這個第三方，此時也須要放入這裏，也防止使用pods一不當心更新掉自定義。

 

五、Resource

 

這裏放置的是工程所需的一切資源，以下

·Fonts 字體

·Image 圖片（固然你能夠添加至Assets.xcassets）

·Sounds 聲音

·Videos 視頻

 

二、基類詳解

這裏着重講解一下VC、V、VM的基類，其餘的模式與View相似因此略過，其中TableViewCell的基類稍微特殊因此也提一下。

目前的基類以下圖：

曾經筆者感受基類不順眼，曾經嘗試將基類所有幹掉，而後遇到了一些麻煩。