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