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

Question

我已经读过将Data Source与ViewController分开是一个好主意,因为它减少了代码膨胀和耦合.

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

1. 我需要指向我的表视图的指针,以便在新数据到达时重新加载它.仅这一点就使得这种解耦很困难,因为数据源知道表视图并通过它了解视图控制器.

2. 现在我需要显示详细视图控制器.现在我需要当前视图控制器的指针.这可以通过表视图或单独的属性来完成.

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

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

Answer 1

由于您对模型视图控制器范例无疑很熟悉,将TableView数据源与控制器分离并不能简单地减少膨胀和可怕的"Massive ViewController"问题.它实际上提升了数据源的可重用性并澄清了控制器的责任.

话虽如此,在今年的WWDC上有一个题为" 高级用户界面与收集视图 "(会话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

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

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