從2010年開始接觸iOS開發(fā)到現(xiàn)在，折騰過不少App的架構(gòu)。從MVC到MVVM，VIPER，MVP，以及最新的ReactiveCocoa都做過實戰(zhàn)嘗試，還有其他變種，諸如猿題庫iOS客戶端架構(gòu)設(shè)計，也做過一些學(xué)習(xí)研究。這些技術(shù)概念如果不熟悉，建議每個鏈接都點開好好研讀下，不要對你的大腦太溫柔。在開始架構(gòu)討論之前，再推薦一些其他非常值得一讀的文章：唐巧－被誤解的 MVC 和被神化的 MVVM， Casa Taloyum iOS架構(gòu)系列文章，objc.io架構(gòu)系列文章。
　　1.應(yīng)用層架構(gòu)定義
　　其實嚴(yán)格來說，MVC和其他類似概念還算不上一個完整的架構(gòu)。一個頗具規(guī)模的App必然會涉及到分層的設(shè)計，還有模塊化、Hybrid機制、熱補丁等等。MVC這種更像是個設(shè)計模式，解決的只是App分層設(shè)計當(dāng)中的應(yīng)用層（Applicaiton Layer）組織方式。對于一些簡單App來說，可能應(yīng)用層一層就完成了整個App的架構(gòu)，不用擔(dān)心業(yè)務(wù)膨脹對后期開發(fā)的壓力。這里我介紹一種新的應(yīng)用層架構(gòu)方式，名之為CDD：Context Driven Design。
　　先明確下我們討論的范疇，什么是一個App的應(yīng)用層呢？現(xiàn)在不少App都會做一個分層的設(shè)計，一般為三層：應(yīng)用層、Service層、Data Access層。每一層再通過面向接口的方式產(chǎn)生依賴。
　　應(yīng)用層是直接和用戶打交道的部分，也就是我們常常用到的UIViewController，負(fù)責(zé)數(shù)據(jù)的展示，用戶交互的處理，數(shù)據(jù)的采集等等。
　　Service層位于應(yīng)用層的下面，為應(yīng)用層提供公共的服務(wù)接口，對應(yīng)用層來說就像是一個Server，不過API調(diào)用的延遲為0ms，Service層里放哪些代碼做法沒有統(tǒng)一的規(guī)范，一般來說會包含業(yè)務(wù)數(shù)據(jù)的處理，網(wǎng)絡(luò)接口的調(diào)用，公共系統(tǒng)服務(wù)API封裝（比如GPS定位、相冊、權(quán)限控制）等等。
　　Data Access層顧名思義是負(fù)責(zé)處理我們App的基礎(chǔ)數(shù)據(jù)，API設(shè)計規(guī)范一般遵循CRUD。這一層位于Service層的下方，提供數(shù)據(jù)庫交互所需的API。
　　這是基礎(chǔ)部分，不同的團(tuán)隊具體做法又會有一些差異。比如有些把Data Access層又叫做Model層，有些把網(wǎng)絡(luò)模塊放在Service層，有些則放在Data Access層，有些把部分的業(yè)務(wù)數(shù)據(jù)放到Model里面做成胖Model，有些則堅持使用瘦Model，把業(yè)務(wù)代碼放在獨立的地方統(tǒng)一管理，等等差異不一而足。除了分層還有一些公共模塊的設(shè)計，比如數(shù)據(jù)庫、網(wǎng)絡(luò)、安全、熱補丁、Hybrid機制、性能監(jiān)測模塊、日志模塊等等如何配合分層設(shè)計，這里就不一一展開了。我們今天討論的重點在應(yīng)用層。
　　首先聲明下，這個CDD其實是我很久之前看Android代碼腦洞出來的，剛好解決了我之前組織應(yīng)用層代碼的一個痛點。做過Android的朋友應(yīng)該都知道，在很多類里都可以通過getContext方法獲取到一個context，再通過這個context可以獲取到其他系統(tǒng)資源。當(dāng)時我第一次了解完這個context概念的時候，瞬間產(chǎn)生了一個這樣的腦洞：
　　
　　我知道這靈光一閃的腦洞有點大，容我慢慢道來。前面提到應(yīng)用層其實是在管理一堆UIViewController。拿微信做例子（我真的很喜歡拿微信舉個栗子），首頁4個tab，4個界面，4個controller，每個controller都有很多UI元素，點擊又可以進(jìn)入二級的controller，各controller可以看成一個獨立的模塊，有些簡單，有些復(fù)雜。比如聊天界面這個controller就非常非常的復(fù)雜。