2

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

但是，有几件事我找不到一个好的答案：

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

  2. 视图应该有多聪明？我可以创建一个显示联系人的视图（通过分配联系人属性）还是应该为所有联系人字段创建单独的属性，或者视图是否应该通过委托调用请求它的信息？

  3. 我在我的应用程序中使用故事板。在我的屏幕上，我想要一个导航栏，让我们说一个显示订单的视图。在其他屏幕上，我想重用订单视图。

    • 如何在其他 ViewController 中重用订单视图的 ViewController 和 View？
    • 如果我有 4 个具有相同外观和感觉的屏幕，我是否必须简单地将它们复制到情节提要中？这似乎很痛苦，如果我想改变我的背景怎么办？或者为所有视图添加一个按钮？当我创建一个设置向导时，我不想分别为每个屏幕定义外观。

来自 C# 背景，我可能必须进入 Objective-C 的心态 :)
对此的任何帮助都会很棒。

4

2 回答 2

5

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

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

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

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

于 2012-08-12T05:44:22.503 回答
1

  1. 这是一个非常抽象的问题，不清楚“层”是什么意思。是的，您应该在适当的情况下创建自己的类，但类别也为您提供了向现有类添加功能的选项。如果您可以更具体地提出问题，则更容易提供更好的答案。

  2. 这是一个判断电话。如果您想创建一个知道如何显示您的联系人类型实例的视图类，这在我的书中很好。但是，如果该视图知道联系人在应用程序中的存储位置，那就不太好了。

  3. 请记住，故事板中的内容是对象，而不是类。您不想尝试在另一个场景中重复使用来自一个场景的视图——这意味着在场景之间共享一个视图，这实际上是行不通的。如果您想在多个地方使用相同的订单视图，那将是创建类的好选择。另一方面，你可以设置你的故事板，让几个不同的场景都过渡到同一个场景。例如，如果您希望应用程序的不同部分以模态方式显示显示订单的场景，您可以这样做。

于 2012-08-12T05:39:24.907 回答