演示控件，自定义视图和更轻巧的UIViewControllers（第1部分）

现在我们有了MVVM，MVP，VIPER，VIP，但是其他部分呢？ 复杂的UI逻辑应该放在哪里？

注意：这是系列文章中的第一篇，我将在其中讨论一些通过抽象UI呈现逻辑来使UIViewControllers变薄的方法。 接下来的帖子将在接下来的几天发布。

当我开始开发iOS应用程序时，我开始使用Apple的首选架构模式Model-View-Controller（MVC）。 我们都知道，MVC导致职责分离非常糟糕。

视图控制器充当视图和模型之间的中介者，并以处理许多杂乱的代码（从UI逻辑和导航逻辑到业务逻辑和API调用）为结尾。

如果您注意到了这一点并搜索了替代方法，则可能听说过MVVM，MVP，VIPER或VIP。 如果您还没有听说过这些，我强烈建议您尝试其中的一些方法（https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52#.6bew98dms）。

人们认为每种MVC替代方案都可以解决一个特定的问题，各有千秋，但是它们都有一个共同点： 它们将逻辑与表示分离开来 ，从而使UI完全可互换。 那太好了。 现在，UIViewController已被隔离，可以无问题地替换为另一种表示方式。 这真的很酷。

当我开始使用MVVM开发自己的应用程序时，我注意到UIViewController变得更薄了，因为它没有任何业务逻辑，但似乎缺少了一些东西。 表示逻辑仍在使视图控制器超出预期，因此我花了一些时间思考并发现了一些解决方案。 今天，我将解释其中的第一个：与视图控制器分离的UITableView协议。

孤立的表格视图

我想从视图控制器中获得的第一件事是UITableViewDataSource和UICollectionViewDataSource。 有些人已经讨论过如何在视图控制器之外获取数据源。

这个想法很简单。 当视图控制器中有UITableViewDelegate和UITableViewDataSource时，我们必须考虑索引，单元格高度，单元格标识符以及许多我们真正不关心的低层概念。 更好的方法是在方程中添加新的分量。 可以将其命名为“表视图”驱动程序，并管理表视图的显示详细信息。

计划

我们将引入一个新组件，该组件将成为UITableView的委托和数据源，并将抽象化视图控制器的细节。

表格视图驱动程序代码

这里有一些注意事项：

1. 表格视图驱动程序存储对其显示的数据的引用。
2. 它还存储对其管理的表视图的引用。
3. 尽管视图控制器不必再担心索引和底层表示的细节，但它可能想了解高层逻辑，例如何时选择项目。
4. 表格视图驱动程序是表格视图的委托和数据源。
5. 最后，它公开了一个高级公共接口，以便视图控制器可以处理它。

简化的视图控制器代码

通过遵循这种方法，视图控制器将不仅更薄，而且更具声明性，并且可以在更高的抽象级别上工作。 让我们看一下简化的视图控制器代码：

有一些重要的注意事项：

1. 我们可以从表视图底层表示逻辑中抽象视图控制器。 但是，视图控制器将继续了解表视图的存在。 这是一个问题，因为我们不能例如在不修改控制器的情况下用UICollectionView替换它。
2. 视图控制器通过强烈引用它来拥有表视图驱动程序。
3. 视图控制器负责实例化表视图驱动程序并将其自身分配为其委托。
4. 视图控制器调用表视图驱动程序的高级方法。
5. 视图控制器是表视图驱动程序的委托。

结论

我们知道，应该通过将视图控制器封装在诸如视图模型或演示者或交互器之类的组件中，将其与业务逻辑隔离开来，但是视图控制器将继续负责底层的表示逻辑。

在本文中，我讨论了一系列方法中的第一个，我们可以使用这些方法将视图控制器拆分为一堆组件，这些组件将只负责演示的一小部分。 第一种方法涉及使用一个对象，该对象处理表视图（或集合视图）表示逻辑，并向表视图公开简化的抽象层接口。

在以下文章中，我将讨论其他方法，例如表示控件和自定义视图（以编程方式以及使用xibs的方式）。

如果您以其他方式执行此操作，我将很高兴听到它。 请在下方留下你的意见！ 谢谢！