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

標籤：ram   入門   微軟   目錄結構   目錄   view   ...   基類   更改   

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在此扮演的更大一部分的角色是更好的解耦，減少代碼複雜度，使代碼層次分明、邏輯清晰便於維護升級。

二、架構部分

1、架構目錄詳解

首先介紹一下本架構的目錄結構，如：

1、Frameworks

存放系統庫的虛擬資料夾，目前搭建架構的時候需要手動添加一個名稱為Frameworks的虛擬資料夾，這樣你在Build phases中添加的系統庫會自動歸入此檔案夾，不會直接在外部顯示以至於打亂目錄結構。系統庫添加流程如下:

細心的會發現此目錄中有兩個相同的Frameworks，這是為什嗎？最上面的那個frameworks是在自己搭架構自己添加的，當時項目還很單純，問題是出在下面那個Pods Target上，添加它之後就會自動給你產生一個旭牛的frameworks的檔案夾，那又該問了，為啥不直接用下面那個呢？（兩者之間並沒有衝突）

2、cocoapods

當開發iOS應用時，會經常用到很多第三方開源類庫，比如JSONKIT，AFNetworking等等。可能某個類庫又用到其他類庫，所以要使用它，必須得下載其他類庫，而其他類庫又用到其他類庫，”子子孫孫無窮盡也“，反正在早期程式員是會體驗到這種痛苦，心酸，手動一個個去下載所需類庫是十分麻煩的。

 

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

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

 

3、AppDelegate

這個目錄下放的是APPDelegate.h(.m)檔案，是整個應用的入口檔案，所以單獨拿出來。一會兒告訴你如何寫一個簡潔的AppDelegate，會在這個檔案夾裡添加一些類，所以將其放入一個檔案夾內還是很有必要的。

4、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一不小心更新掉自訂。

 

5、Resource

 

這裡放置的是工程所需的一切資源，如下

·Fonts 字型

·Image 圖片（當然你可以添加至Assets.xcassets）

·Sounds 聲音

·Videos 視頻

 

2、基類詳解

這裡著重講解一下VC、V、VM的基類，其他的模式與View類似所以略過，其中TableViewCell的基類稍微特殊所以也提一下。

目前的基類如：

曾經筆者感覺基類不順眼，曾經嘗試將基類全部幹掉，然後遇到了一些麻煩。

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