objective-c - iOS架构和组件

Question

很长一段时间以来，我一直在查看 objective c 示例，观看斯坦福大学的讲座，并尝试使用一些代码来掌握创建 iOS 应用程序的窍门。

但是有几件事我找不到好的答案:

1. 如何正确分离图层？我了解 MVC 结构，并且看到了一些为模型创建 Categories 以实现业务逻辑的示例。这是正确的方法吗，通过丰富模型还是我应该创建专用类(例如，对用户进行身份验证、从 json 中提取模型、分组订单)？

2. View 应该有多智能？我可以创建一个显示联系人的 View (通过分配联系人属性)，还是应该为所有联系人字段创建单独的属性，或者 View 是否应该通过委托(delegate)调用请求它的信息？

3. 我在我的应用程序中使用了 Storyboard。在我的屏幕上，我想 有一个导航栏，让我们说一个显示订单的 View 。在 我想重用订单 View 的其他屏幕。

   • 如何在其他 ViewController 中重复使用 order-view 的 ViewController 和 View？
   • 如果我有 4 个具有相同外观和感觉的屏幕，我是否必须简单地将它们复制到 Storyboard 中？这对 main 来说似乎很痛苦，如果我想更改我的背景怎么办？或者在所有 View 中添加一个按钮？当我创建一个设置向导时，我不想为每个屏幕单独定义外观。

来自 C# 背景，我可能必须进入 objective-c 思维模式:)
在这方面的任何帮助都会很棒。

Answer 1

1) ObjC-Categories 很容易扭曲您对所面临的主要问题的理解。 ObjC 类别完全没有必要。您始终可以通过子类化、对象组合、实际模型中的其他方法或 Controller 或 View 中的某些自定义来实现这些扩展。因此，如果您需要格式化数据(例如模型中存在的数据)以便在 View 中显示——该任务通常会落在 Controller 中。就您提供的示例而言:您可以在简单的情况下选择模型——同样，如果足够复杂或者它会让您避免冗余实现，那么任何示例都值得专门上课。请注意，这些可能是附属类，它们只是生成一个模型，或者它们可能是多个具体抽象类的组合。并非所有内容都需要完全符合 M-or-V-or-C 的定义。您可以自由使用 ObjC 的许多设计模式。将 MVC 视为 Cocoa 通常使用的模式——您将需要了解它们，并且您将需要知道如何子类化和扩展这些类型，但随着实现远离 Cocoa 的库(例如，随着复杂性的增加)，这些模式将失去主导地位.

2) 他们可以很聪明。但是，在 MVC 下，您希望将其实现集中在 View /表示方面。表示信息集合的 View 实际上可以执行一些通常为 Controller 保留的任务——但是，您通常会承认该实现是一个专用的 MONContactView 这样做。如果你走那条路，你通常会这样做是为了便于重用或实现简单的界面。显示有关 Contact 的信息可能非常复杂 - 在简单的场景中，这些任务通常由 Controller 处理。具体来说，MONAwesomeContactView 可能比 MONAwesomeContactViewController 更简单(例如在 SLOC 中)(除非您要执行一些非常特殊的绘图或布局)。更常见的做法是设置 Controller 的联系人，然后让 Controller 将联系人数据推送到 View 的字段。同样，在非常特殊的子类的情况下——在某些情况下， View 可以很好地拥有自己的 Controller 。

3a) 创建一个类的多个实例没有错。

3b) 无需复制。当发现重复时，我将实现推送到实际代码中——程序可以应用您想要的外观，或者根据需要添加或操作 subview 。当然，它们不会出现在 Xcode 的 NIB 编辑器中。当然还有其他方法，但这种复制常常让我将实现转移到编译代码中。实现两者的良好平衡并不难(就个人而言，我的大部分观点都是以编程方式进行的，而不是使用 NIB)。