Question

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

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

我需要指向我的表视图的指针，以便在新数据到达时重新加载它。仅此一点就会使这种解耦变得困难，因为数据源知道表视图并通过它了解视图控制器。
现在我需要点击显示详细视图控制器。现在我需要当前视图控制器的指针。这可以通过表格视图或单独的属性来完成。

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

在视图控制器中使用分离数据源有什么好处？

Answer 1

由于您对模型视图控制器范例无疑很熟悉，将TableView数据源与控制器分离并不能简单地减少膨胀和可怕的“大规模ViewController”问题。它实际上促进了数据源的可重用性并澄清了控制器的责任。

话虽如此，世界自然基金会今年的题目是“Advanced User Interfaces With Collection Views”（会议232）。我恳请您观看此视频，因为我们可以在第一时间看到Apple团队的iOS团队所使用的架构模式。

在视频中，您将看到他们的集合视图单元格实际上是从数据源返回的。更进一步，它们实际上创建了将多个数据源组合成一个通用模型的聚合数据源。这样，您最终会得到一个允许您在任何视图控制器中重用单元的体系结构。所需的只是设置适当的数据源。

关于你的第一点：需要一个指向tableview的指针。这不是真的。您的数据源可以通过委托回调与控制器通信，通知控制器在某些索引路径重新加载单元格。

同样，如果您需要轻松处理点击事件，则点击处理仍然可以驻留在您的控制器中。您可以简单地询问您的数据源，以便为给定的索引路径返回哪个控制器。

作为一个简单的例子，想象一下我们有一个桌面视图，显示票房中的顶级电影列表及其实时评级。

现在我们要创建数据源。数据源应负责从服务器获取信息，返回使用正确数据配置的相应单元，并使用表视图注册可重用单元。此信息也是实时信息，因此可能随时更新，因此数据源需要与控制器通信以发出更新信号。

所以我们的电影资料来源可能如下：

@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

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

当您开始决定多个数据源时，这种设计自然会变得更具吸引力。诀窍是查看表视图中的哪些单元应属于特定数据源，因为此处的关键是提升可重用性。然后，您可以继续设计管理自己子节点的聚合数据源。

从UITableViewController分离数据源有什么好处？

1 个答案: