如果相关类至少采用 UITableViewDataSource，则 UITableView 可用于创建列表视图。我有以下问题：
为什么会设计成基于 section 和 row ，通过数据源方法创建控件并返回给 UITableView 实例。为什么不在 UITableView 实例中提供所有这些信息而不使用 UITableViewDataSource。会有什么不同？
EDIT1： @hermann 和@JOhn：你提到它打破了 MVC 模式。让我们假设我自己正在创建一个自定义 UITableView，比如控件。我设计它的方式是不将数据直接传递给 UITableView，而是传递需要在行和部分中添加的相关子视图及其相关标题。我认为这不会破坏 MVC ..我正确吗？但它仍然存在当前 UITableView 实现风格解决的问题。重用控件和图像的能力，而不是膨胀的内存使用。
首先，这样做可以坚持 MVC 模式。UI 对象，也就是视图，永远不应该直接与模型通信，也就是业务数据。另外它不应该执行任何属于控制器的业务逻辑。
其次，它更灵活，无需继承 UITableView 对象。
第三，从性能和内存管理的角度来看，完整的概念非常有效。无需预先加载所有可能显示在表格中的数据，而是可以在“现在需要知道”的基础上及时获取或计算它或任何其他数据。此外，一旦使用委托/数据源方法提供数据，就可以释放数据容器，尤其是像图像一样消耗内存的容器。
当然，UITableView 的子类原则上也可以这样做。我只是怀疑这会导致更可维护的代码，甚至可以节省任何时间或分别工作。
如果您不想坚持使用 MVC，那么可以随意对表视图进行子类化并在其 init 方法中传递其所有数据，或者使表视图子类能够从 web 服务或数据库或任何地方加载所有数据. 当您遇到问题并返回给我们寻求指导时，请准备好接受一些讨厌的答复，例如“为什么不坚持既定的最佳实践或 MVC 模式？” 等等。
如果您的表格只显示一些相当静态的值，例如，如果它只是用作进一步导航钻取的菜单等，那么这个概念可能看起来有点荒谬。但这也不痛。当涉及到更复杂的数据提供任务时，它当然有其优势。
给它一个机会。试试看！
对于 MVC，您希望尝试清楚地区分模型、控制器和视图的职责。通过允许视图（tableview）向委托请求数据，可以创建非常通用的视图。
使用委托模式，控制器可以以任何需要的方式“暂存”数据，然后在 tableView 需要时将其提供给 tableView。tableView 不关心数据来自哪里，如何转换，使用什么 ADT，什么都没有。它完全不知道数据在哪里或是什么。它只知道它应该在这个位置为这个部分和行显示这个字符串。