1

我正在编写一个带有几个（可能是 8 个）调查式模块的 iOS 应用程序，用户将在其中回答一系列问题（关于家庭生活、健康等）。有些模块有多达 12 个问题。每个问题都有自己的 nib 和自己的 UIViewController。理想情况下，答案将在模块结束时写入数据库。每个模块对应一个表中的一条记录。永远只有一个用户，因此只有一个记录。我想将核心数据堆栈留在应用程序委托中。我目前正在从视图控制器创建核心数据对象。

我一直在努力寻找：

  1. 将累积数据传递到 UIViewController 的长线性链的最佳方式。
  2. 另一种解决方案。

我知道以下可能性：

  • 通过视图控制器的重载初始化程序将数据数据沿链传递，使用在每次传递时添加的集合
  • 再次使用集合将数据传递给子视图控制器中的属性
  • 在应用程序委托中使用全局变量（我不认真考虑这是一个选项）
  • 使用单例类

我认为在这种情况下，单例被认为是最好的选择，至少在设计方面，但我的研究到目前为止，我还没有听说有人使用这么多（8 个，也许更多）单例。他们引起如此多争论的事实使我感到困惑。而且我有时会看到多线程与单例一起讨论，但我不明白为什么它们会齐头并进（如果他们甚至这样做的话）以及我将如何处理它。最后，如果我要使用单例，我会从单例还是从视图控制器调用核心堆栈？

编辑：如果我使用单例，另一个问题是 - 我如何处理我的核心数据实体类？我可以或应该使用单例类来替换它们吗？

将不胜感激对上述和/或解决方案的替代建议的回答。如果可能的话，我想在好的设计和简单/快速的实现之间找到一个折衷方案。更改应用程序设计不是一种选择（客户正在确定布局和流程）。

4

1 回答 1

2

作为一名从事过大量 iOS 项目的工程师，我已经尝试了您刚才提到的所有方法。到目前为止，最干净和最可维护的解决方案是使用单例。

为什么？从重构的角度考虑您的代码。您有一个过程（将类型为 answer 的对象推送到 Core Data 堆栈），您在不同的视图控制器中重复了很多次。如果您不喜欢答案处理代码中执行某些操作的方式，则需要更改该代码的相关部分，因为它已在您的应用程序中出现。逐个视图控制器进行适当的更改比在一个地方进行更改要乏味得多。这似乎很明显，但在设计任何应用程序时，这是一个深刻的事实。

让我们考虑在视图控制器链中传递一个累积对象。无论是通过属性还是通过为视图控制器子类创建新的指定初始化程序来执行此操作，您都需要编写样板代码以将对象从一个视图控制器传递到下一个视图控制器。鉴于您对每个问题如何拥有自己的 UIViewController 子类的描述，这意味着您将在每一步都受类型安全的支配，只是为了移动数据。如果您明天决定要更改要传递的数据类型怎么办？即使您有一个特殊的 UIViewController 子类来集中所有其他控制器继承的样板代码，您仍然会遇到相同的问题，即在代码中散布随机分配只是为了将数据保留在那里。和你'

现在考虑一个单例。单例非常棒，因为它可以拥有和管理最好的单一数据集，而且可以让应用程序的任何部分都可以访问它。想想你会想到 UIDevice 的单例。你只会处理一个 UIDevice —— 类似地，你只会处理一个核心数据堆栈或一组数据。为什么不认识到这一点并尝试从那里分解您的代码？

不幸的是，Apple 在 Storyboards 中的示例让人认为依赖注入是您将数据从一个视图控制器传递到下一个视图控制器的唯一方法。与其尝试去思考其他工程师对某些实践的看法，不如尝试确定您自己使用的每种方法的优缺点。如果你不完全理解它们，试一试，看看结果如何。其中很多都是反复试验，建筑设计也不例外。

编辑正如 Inafziger 所说，在多个线程上存储（在某些情况下读取）数据时，单例是棘手的。如果您正在从多个线程写入单例，请构建您想要的任何类型和大小的调度队列并在单独的线程上运行它（或将其添加到主线程上的运行循环）。如果您不处理多个线程，那么单例非常棒:)

顺便说一句，在 Objective C 中创建单例的最佳实践可以在这里找到。

于 2012-10-25T23:43:09.477 回答