Xcode 这些对在开发iOS 6应用程序时使用故事板仍然是有效的否定吗？

使用故事板代替传统的.xib策略是我仍在努力解决的问题，因为在没有真正了解它在做什么以及我真正失去了什么控制的情况下，采用一些在幕后做了很多事情的东西会有些犹豫

BNR iOS编程书强调了使用故事板的几个“缺点”。我在下面列出了它们，我的问题是：这些负面信息在iOS 6上仍然有效吗？

故事板在团队中很难使用

故事板破坏了版本控制

故事板扰乱了编程流程

故事板牺牲了灵活性和控制以便于使用

故事板始终创建新的视图控制器实例

我正在寻找那些真正在构建、最好是部署真正的iOS应用程序，并且自己也在为“故事板vs.xib”而挣扎的人的答案

---

谢谢

我认为iOS 6无法解决这些问题。更重要的是，xcode 4.5没有修复它们，甚至没有尝试这样做。列出的问题似乎反映了观点或风格偏好，也许还有一些错误信息。这些都不是可以在代码中修复的东西

我正在为一个重要的应用程序使用故事板，我发现它们是一个真正的生产力优势。我鼓励你尝试一下，看看你是否同意

对问题列表的几点评论：

我不知道团队和SBs有什么问题，但是如果2是真的 （事实并非如此）这可以解释这种担忧。我想这是一个好主意 基于2的误解

不是真的。我虔诚地使用Git，并经常提交。没问题。在提交期间，SBs以其源代码形式（XML）显示。这些差异工作得很好，实际上为SBs的实现提供了一些见解。这减少了神秘的“隐蔽”行为的感觉，而这种行为与熟悉无关

不同意。它们不会破坏能量流，而是提供一种不同的能量流——这就是它们获得能量的地方。许多程序员在MVC规则强加的分离中发现了价值。SBs在UI元素放置和支持代码之间引入了分离。这是一种自然的分离，消除了大量无意识的代码（这消除了打字错误的机会，并“消除”了剩余的真实代码）

部分同意-它们确实提高了易用性。但我没有发现任何牺牲。即使在使用SBs时，如果需要，您也可以恢复手动编码任何对象。没有牺牲灵活性或控制力

不确定这意味着什么，以及为什么这可能是一个问题。当然，我们为不同的场景制作不同的VCs——这很自然。但是在SBs中重用VC类当然是可能的。此项可能是关于如何为SB对象设置类的误解。这一步很容易忘记，有时初学者也会感到困惑。但是，纠正这些错误是微不足道的，设置类很快就会成为一种习惯 对我来说，真正的担忧是：

使用SBs需要大量屏幕房地产进行开发。在小型显示器上使用SBs可能会令人沮丧

具有许多场景的高度复杂的UI应分割为多个SBs。完全支持多个SBs，但很容易失败。（这就像重构一个变得太大的方法。通常我会注意到我需要在某些东西变得混乱后对代码进行折射。）

SBs在布局过程中的便利性以及消除了使VC对象混乱的大量样板代码是一个巨大的好处。（我消除的每一行代码都是一行我不能搞糟的代码，也不能掩盖剩下的真正代码。）

---

简言之，我无法想象没有SBs还能活下去。是的，这是一个变化。但我没有发现任何真正严重的缺点。特别重要的是要记住，即使在使用SBs时，所有非SB编码技术仍然有效。给某人一次机会，并报告你自己的经历。祝你好运

我大体上同意朱贝尼的观点。我在你的观点中看到的唯一“有效”的批评是关于“故事板总是创建一个新实例”。基本上，这意味着，尽管你可以连接一个按钮来推动堆栈上的视图控制器，但如果没有额外的代码，你不能连接一个按钮来弹出堆栈。这在Xcode 4.5中通过“退出序列”得到了解决，它允许您指示您希望弹出到以前的控制器，而不是创建新实例

许多人抱怨的故事板的另一个限制是不能在故事板本身中嵌入子视图控制器。Xcode 4.5中也提到了这一点

故事板是iOS开发的重要一步。诸如“合并困难”之类的抱怨是毫无根据的；故事板并不比其他代码更难合并；你只需要花点时间实际阅读差异，而不是把它美化成“不是Obj-C；无法阅读”

---

自从故事板推出以来，我已经成功地在团队环境中使用了它们。不要让无知的人吓跑你。他们很棒

还有一点，在2012 WWDC库中有一个非常有用的讨论，关于如何将SB对象添加到现有项目中，而不将所有内容转换为SB。这里是：故事板可能并不比xib更难合并，但在团队中工作时，您需要合并SB的可能性要高得多。在中型项目中使用多个故事板实际上可以减少代码合并的麻烦-特别是如果故事板功能部门与团队职责一致的话。（使用大量故事板的一个缺点是，故事板之间的分隔不太流畅。但这一问题在干净的设计中并不常见，并且在需要时是可行的。）故事板显然是留下来的，而不是pe