一、更轻量的 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
