一、更輕量的 View Controllers
1.把 Data Source 和其他 Protocols 分離出來
把 UITableViewDataSource 的代碼提取出來放到一個單獨的類中，是為 view controller 瘦身的強大技術之一。
實際上，UITableViewDataSource 相關的代碼基本都是圍繞數組做一些事情，我們可以嘗試把數組相關的代碼移到單獨的類中。我們可以創建一個 ArrayDataSource 類的實例作為 table view 的 data source，并通過這個類提供一個 block 來設置 cell，也可以用 delegate 來做這件事，這取決于自己的習慣。
這種方法也可以擴展到其他 protocols 上面。最明顯的一個就是 UICollectionViewDataSource。這給了你極大的靈活性；如果，在開發的某個時候，你想用 UICollectionView 代替 UITableView，你幾乎不需要對 view controller 作任何修改。你甚至可以讓你的 data source 同時支持這兩個協議。
2.將業務邏輯移到 Model 中
- 將比較獨立的，只與 model 本身相關的邏輯，移到 Model 中去處理；
- 借助分類 category 來分擔部分任務；
3.創建 Store 類
有些與 Controller 本身無關的數據加載邏輯，比如加載一些本地文件并做些處理，可以由 store 工具類來單獨處理，Controller 只需要關心結果就行。Store 對象會關心數據加載、緩存和設置數據棧。它也經常被稱為服務層（service layer）或者倉庫（repository）。
4.把網絡請求邏輯移到 Model 層
將網絡請求本身的邏輯（如緩存、錯誤處理和 validation等）交給 Controller 之外的類去處理，Controller 本身只需要關注該關注的東西就行了，比如傳參、回調。所以我們通常會有一個網絡層。（推薦源碼：RTNetworking、YTKNetworking）
5.把繪制 View 相關代碼移到 View 層
不要在 view controller 中構建復雜的 view 層次結構，一般我們可以把 views 封裝到一個 UIView 子類當中，也就是設計自定義 view。需要注意的是，封裝自定義 view 要時刻不忘 DRY 原則，同時也要考慮避免過度耦合問題。
6.通訊
- 關于 view controllers 和 model 對象之間的消息傳遞，已經有很多闡述得很好的技術（比如 KVO 和 fetched results controllers）。
- view controllers 之間的消息傳遞稍微就不是那么清晰了。當一個 view controller 想把某個狀態傳遞給多個其他 view controllers 時，就會出現這樣的問題。較好的做法是把狀態放到一個單獨的對象里，然后把這個對象傳遞給其它 view controllers，它們觀察和修改這個狀態。這樣的好處是消息傳遞都在一個地方（被觀察的對象）進行，而且我們也不用糾結嵌套的 delegate 回調。這其實是一個復雜的主題，我們可能在未來用一個完整的話題來討論這個主題。
擴展閱讀
- View Controller Programming Guide for iOS
- Cocoa Core Competencies: Controller Object
- Writing high quality view controllers
- Stack Overflow: Model View Controller Store
- Unburdened View Controllers
- Stack Overflow: How to avoid big and clumsy UITableViewControllers on iOS
- Lightweight iOS View Controllers
