故事板设计模式（分享或不分享）

Question

这可能在很大程度上是优惠的，但我想知道是否有任何理由来决定这种或那种方式。

在用故事板进行设计时，您总是会看到许多视图控制器。我正在研究严格MVC方法的开销，其中每个控制器都在它自己的UIViewController子类中实现，并具有相应的UIView子类（甚至MVVM的视图模型类），并且这似乎很快就会失控 - 它不需要时间将几十个文件添加到项目中（很多功能很少）。另一种方法是将所有视图链接到代表所有故事板功能的通用控制器。

我的倾向是，如果你没有实际控制代码的任何个人视图控制器，然后将其全部组合成一个不应该伤害到代码的可读性（以及可增强其在添加大量的源文件）。另一方面，如果你对任何特定的视图控制器都有很强的功能，那么它应该封装在它自己的控制器中。

在大多数情况下，我会将所有控制器构建为尽可能重用（封装在自己的自定义UIViewController子类中）。尽管故事板看起来是针对通常没有几个入口点的视图序列，但它还是有趣的。如果你没有在每个VC（视图控制器）多的功能将它们合并所有的代码放到一个VC

Answer 1

你的想法是正确的

• 。这种方法唯一的缺点是你无法实现视图特定的代码，并且你将使用这个普通VC的每个视图将执行相同的代码，无论它是否需要它。例如在viewWillAppear中等等
• 同样，如果你有很多的功能，对特定视图代码，然后它能够​​更好地把它放在自己的VC
• 这只是一个建议，如果你需要使用多个之间的一些共同的代码逻辑然后VC代替复制并粘贴到相同代码的每个VC中，使其成为Category类型的方法，然后在需要时调用它。所以只能在1个地方更改代码。

更多风险投资并不一定意味着糟糕的设计。在我看来，更容易保持这种方式。我的两分钱。 :-)

Answer 2

故事板中的每个场景应该有它自己的UIViewController子类。即使这样做，获得巨大的不可维护视图控制器（MVC = Massive View Controller）也太容易了。将多个场景的所有代码放在同一个视图控制器中会产生更大的代码，并且违反单一责任原则。每个班级只应做一件事。

这也意味着你不应该将通用的功能复制到你的所有UIViewController子类中。然后他们又会做很多事情 - 常见的东西和他们的实际目的。相反，您可以将您的通用代码放在其他控制器对象（不是UIViewController的后代）中，并将它们用在您的视图控制器中。

根据用例，通用基类也可以工作，但总是最好使用组合而不是继承。

其他控制器对象的另一个好处是，您也可以直接在Interface Builder中添加它们，并将动作和插座连接到它们。你的主视图控制器类通常不需要知道它们存在。