iOS應用層架構的定義及CDD詳解

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