ios - Data Source 和 UITableViewController 分离有什么好处？

Question

我读到将数据源与 ViewController 分开是一个好主意，因为它减少了代码膨胀和耦合。

所以我决定制作一个单独的对象作为我的 TableView 数据源。一切都很好，花花公子，直到我需要这些:

1. 我需要指向我的 TableView 的指针，以便在新数据到达时重新加载它。仅这一点就使这种解耦变得困难，因为数据源了解 TableView 并通过它了解 View Controller 。

2. 现在我需要在点击时显示详细信息 View Controller 。现在我需要当前 View Controller 的指针。这可以通过 TableView 或作为单独的属性来完成。

所以在我看来，这两件事消除了任何脱钩或分离，只会增加复杂性。

与在 View Controller 中使用相比，分离数据源有什么好处？

Answer 1

您无疑熟悉 Model View Controller 范例，将 TableView 数据源与 Controller 分离并不能简单地减少膨胀和可怕的“Massive ViewController”问题。它实际上促进了数据源的可重用性并明确了 Controller 的责任。

话虽如此，今年的 WWDC 上有一场精彩的演讲，名为“Advanced User Interfaces With Collection Views”(第 232 节)。我强烈建议您观看此视频，因为我们可以从中第一次真正了解 Apple 的 iOS 团队所采用的架构模式。

在视频中您将看到它们的 Collection View 单元格实际上是从数据源返回的。更进一步，他们实际上创建了聚合数据源，将多个数据源组合成一个通用模型。通过这种方式，您最终会得到一个架构，该架构允许您在任何 View Controller 中重用单元格。所需要做的就是设置适当的数据源。

关于您的第一点:需要指向 TableView 的指针。这不是真的。您的数据源可以通过委托(delegate)回调与 Controller 通信，通知 Controller 重新加载特定索引路径处的单元格。

同样，如果您需要处理点击事件也很容易，点击处理仍然可以驻留在您的 Controller 中。您可以简单地询问您的数据源，为给定的索引路径返回哪个 Controller 。

举个简单的例子，假设我们有一个表格 View ，显示票房最高的电影列表及其现场收视率。

现在我们要创建我们的数据源。数据源应该负责从服务器获取信息，返回配置有正确数据的适当单元格，并在 TableView 中注册可重用的单元格。此信息也是实时的，因此可能会随时更新，因此数据源需要与 Controller 通信以发出更新信号。

所以我们的电影数据源可能如下所示:

@interface FilmDataSource : NSObject<UITableViewDataSource>
@property (assign,nonatomic) id<FilmDataSourceDelegate> delegate;
- (void)registerReusableViewsWithTableView:(UITableView *)tableView;
- (void)reloadContent;
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath;
@end

@protocol FilmDataSourceDelegate <NSObject>
- (void)dataSource:(FilmDataSource *)dataSource didUpdateItemsAtIndexPaths:(NSArray *)indexPaths;
- (void)dataSourceDidRequestReload:(FilmDataSource *)dataSource;
@end

请记住，数据源还将知道是否有任何请求失败，因此可能会返回带有重试按钮的单元格。数据源可以处理刷新请求，并在获取信息时触发对 Controller 的更新。

当您开始决定使用多个数据源时，这种设计自然会变得更具吸引力。诀窍是查看 TableView 中的哪些单元格应属于特定数据源，因为这里的关键在于提高可重用性。然后您可以继续设计一个聚合数据源来管理它自己的 child 。