shannonchenchn / ios-app-architecture Goto Github PK

这篇文章按照架构的演进顺序，通过用三种不同的设计模式（MVC、MVP、MVVM）来实现一个示例场景，分别讲解了三种不同的设计模式各自的优缺点。

这篇文章主要讲解了如何写好一个列表这个最熟悉的主题，分别讨论了以下几个问题：

• 如何优雅地处理 UITableView 的代理方法和数据源方法，以提高代码的复用性和可维护性
• 网络请求和解析数据的逻辑该怎么处理
• 下拉刷新和上拉加载更多的逻辑怎么处理

核心问题是如何减轻业务方的负责。

关联话题：

• Objective-C 编程之道：iOS 设计模式解析

• 什么是 MVVM
• 为什么要用 MVVM，试图解决什么问题
• 什么时候用 MVVM
• MVVM 的特点，优缺点
• 怎么使用 MVVM 构建 iOS 应用

相关主题：ReactiveCocoa，编程范式

• iOS 应用架构到底是什么？
• 讨论架构要看哪些问题？
  • 解决什么问题
    • 规范
    • 解耦
    • 复用
  • 模块分层
    • View 层
    • 网络层
    • 数据存储层、动态化
    • 工具类、分类
• 几种架构模式
  • MVC
  • MVCS
  • MVP
  • MVVM
  • VIPER
• 几个小问题
  • 在 MVC 模式下，ViewController 到底是 View 还是 Controller？
  • 设计架构时的妥协：灵活性（更多的选择） VS. 规范性（更多的约束）
  • View 如何与 Model 解耦？
    • 协议/代理
    • 分类
    • ViewModel/Reformer
  • 是什么导致了Massive View Controller？
  • 如何给 Controller 减负？（核心：拆分 controller）
    • 迁移 UITableView 和 UICollectionView 的代理方法
    • 封装 view
    • 数据加工的逻辑交给 model 层处理
    • 拆分部分任务到 category 中
  • view 层的事件传递的最佳实践？
    • view 层次太多，传到 controller 的话，就会有很多胶水代码（delegate 或者 target-action、block、基于 responder chain 的事件传递等）
    • 如果一个页面中所有的 view 的事件都交给 controller 处理，那么如何保证复用性呢？
• 结论
  • 没有银弹
  • 只有合适的架构，没有最好的架构

原文：Much ado about iOS app architecture