很长一段时间以来，我一直在寻找客观的c例子，观看斯坦福大学的讲座，并玩一些代码，以便掌握创建iOS应用程序。
然而，有些事情我找不到合适的答案：
如何正确分隔我的图层？我理解MVC结构，并且我看到了一些为模型创建类别以实现业务逻辑的示例。这是正确的方法，通过丰富模型或我应该创建专用类（例如，验证用户，从json，组订单中提取模型）？
观点应该有多聪明？我可以创建一个显示联系人的视图（通过分配联系人属性），还是应该为所有联系人字段创建单独的属性，还是视图应通过委托调用请求它的信息？
我在我的应用程序中使用了Storyboard。在我的屏幕上，我想 有一个导航栏，让我们说一个显示订单的视图。上 其他屏幕我想重用订单视图。
来自C＃背景我可能不得不进入客观的心态:) 对此的任何帮助都会很棒。
答案 0 :(得分：5)
1）ObjC-Categories很容易扭曲您对所面临的主要问题的理解。 ObjC-Categories完全没必要。您总是可以通过子类化，对象组合，实际模型中的其他方法或控制器或视图中的某些自定义来处理这些扩展。因此，如果您需要格式化数据（例如，模型中存在的数据）以便在视图中显示 - 该任务通常会落在控制器中。就您提供的示例而言：您可以在简单的情况下选择模型 - 同样，任何示例都可能值得专用的类，如果足够复杂或者它会使您免于冗余实现。请注意，这些可能是附件类，它们只是生成模型，或者它们可能是多个抽象类的具体组合。并非所有内容都需要在 M-or-V-or-C 的定义中正确定位。您可以使用ObjC自由使用许多设计模式。将MVC视为Cocoa通常使用的模式 - 您将需要了解它们，并且您将需要知道如何子类化和扩展这些类型，但这些模式失去了主导地位，因为实现远离Cocoa的库（例如，随着复杂性的增加）
2）他们可以很聪明。但是，在MVC下，您希望将其实现集中在视图/表示方面。表示信息集合的视图实际上可以执行一些通常为控制器保留的任务 - 但是，您通常会放弃该实现是专用的MONContactView。如果你走这条路，你通常会这样做，以便于重用或实现简单的界面。显示有关Contact的信息可能非常复杂 - 在简单的场景中，这些任务通常由控制器处理。具体来说，MONAwesomeContactView可能不如MONAwesomeContactViewController那么复杂（例如在SLOC中）（除非您有一些非常特殊的绘图或布局要执行）。设置控制器的联系人更常见，让控制器将联系人数据推送到视图的字段。同样，在非常专业的子类的情况下 - 在某些情况下，视图可以很好地保存自己的控制器。
3a）创建一个类的多个实例没有任何问题。
3b）无需复制。当闻到重复时，我将实现推送到实际代码 - 程序可以应用您想要的外观，或者根据需要添加或操作子视图。当然，它们不会出现在Xcode的NIB编辑器中。当然有替代方法，但这种复制经常使我将实现移动到编译代码。实现两者的良好平衡并不是那么困难（就个人而言，我以编程方式执行大部分观点，而非使用NIB）。
答案 1 :(得分：1)
这是一个非常抽象的问题，并不清楚'层'是什么意思。是的，您应该在适当的位置创建自己的类，但类别还为您提供了向现有类添加功能的选项。如果您对问题更具体，那么提供更好的答案会更容易。
这是一个判断电话。如果你想创建一个知道如何显示你的联系人类型实例的视图类，这在我的书中很好。如果该视图知道联系人存储在应用程序中的位置，那就不太好了。
请记住，故事板中的内容是对象，而不是类。您不想尝试从另一个场景中的一个场景重新使用视图 - 这意味着在场景之间共享视图，这实际上是行不通的。如果你想在几个地方使用相同的顺序视图，那么这对于创建一个类来说是个很好的选择。另一方面，您可以设置故事板，以便几个不同的场景都转换到同一个场景。例如，如果您希望应用程序的不同部分以模式方式显示显示订单的场景，则可以执行此操作。