程序界面与Swift中的Storyboard

在Swift社区中，有关如何构建用户界面的讨论一直在进行中。 我得出的结论是，这取决于个人喜好或公司的选择，直到我开始在拥有较大iOS团队的公司工作时。 我想分享一下我的观点随着时间的变化，这可能会帮助您选择一种更好的方式来构建应用。

使用Storyboard构建/查看用户界面太容易了。

假设您加入了一个团队，并且需要在现有代码库的基础上构建一个新功能。 如果所有内容都是以编程方式构建的，那么您可能需要花一些时间来弄清楚什么是什么，需要使用哪些UI组件等等。单击几下，这些问题就不会是Storyboard的问题。

但是Storyboard有几个问题，我找不到解决方案。

将数据传递到Storyboard创建的另一个视图并不理想

将数据传输到另一个视图的最流行的方法是，在创建实例或使用函数performSegue（withIdentifier：sender :)之后，立即将其立即传递给实例。

这种处理将数据发送到另一个视图的方法不是理想的，因为它是在团队中的每个人都了解我们将数据传递给视图的工作原理的前提下进行的。

假设您创建了一个场景，该场景显示了从数据服务器获取的对象列表，并且当用户单击一行时，我们选择了一个场景，该场景显示了所选对象的详细信息。

上面的方法不是最好的方法的原因是，即使不需要，对象属性也必须公开给外界。 这可能会导致如果分配了另一个对象，则可能导致错误。 然后，这种类型的代码希望团队中的每个人都知道在创建实例后detailViewController需要该对象。 如果您的项目有50个以上的场景，那每个人怎么知道每个场景具有的每个需求呢？ 这可能会导致无效的发展。

如果继续以编程方式构建此视图控制器，它将看起来像这样。

如您在上面看到的，当我们初始化对象时它需要对象，因此编译器会在编译时对其进行检查。 这样，可以使未创建此视图控制器的开发人员得到所需的数据通知，以使该视图控制器正常工作，而无需花费时间去研究代码。

使用Storyboard修复某些东西时，它变得稍微复杂了一点。

如果在Storyboard中创建UI组件并在代码中进行设置，则有两个容器需要维护，即代码或Storybase。 例如，当您需要在特定的位置查找代码时，您需要设置表视图的委托，因此您必须检入代码和Storyboard，因为您可以通过两种方式进行设置。

好吧，这实际上是一个有趣的部分。 我长期以来一直主张仅将编程代码用于用户界面。 现在，我在一家银行工作，该公司的应用程序具有大量具有许多功能的场景。 我记不清多少时间我对Storyboard创建的所有场景表示感谢。 很容易看到流程，很容易理解是什么，很容易处理任何错误。

关于应该采用哪种方式，我仍处于围栏。 说您可以根据自己的喜好或您更看重的东西选择它是更正确的选择。 我仍然更喜欢程序化UI，而不是Storyboard，但这是我个人的选择。 希望我的意见能帮助您理解以前可能遇到的某些问题。 最后，这是一个选择，而不是一个要求！

感谢收看！