1

作为一种良好的设计实践，在应用程序中开始使用 Core Data 对象作为模型并将它们传递给 ViewController 或将所有模型保留为 NSObject 并让它们负责创建 NSManagedObject 并在我们调用 save 时自行存储它们是否安全？

如果我突然想将一个普通 NSObject 的 Object 存储到 Core Data 中，那么要遵循什么通用架构可以很容易地撤消特定屏幕中的某些内容？

4

1 回答 1

2

在 Web 应用程序中，很大程度上取决于全局架构，以决定是使用域对象还是占位符对象。在 Java 世界中，这意味着在实体类或 Java bean 之间进行选择。

但根据我的经验，在 iOS 应用程序中，我不得不说直接使用 NSManagedObject 要好得多。这样做有很多好处，我现在很快就能想到三个：

  1. 当不需要对象时，Core Data 会处理故障，因此您不必担心内存管理和资源释放。
  2. 使用和修改 NSManagedObjects 会带来一堆 NSNotifications，你可以用它们来驱动你的 UIViews。
  3. 在处理大量数据（即 UITableView 和获取的控制器）时也会有好处。

关于 NSManagedObjectContext 的数量，有些人可能会觉得这很奇怪，但我会这样做。如果您的应用程序很简单，UITableView 和一些 UIView 细节，并且您也不打算从网上进行一些频繁的非常大的更新，我认为遵循 Xcode 模板就足够了。也就是说，让 AppDelegate 或您创建的另一个工厂类（例如 MyAppCoreDataController）为一个且唯一的上下文提供服务，将为您节省很多关于创建和合并 NSManagedObject 并因此刷新视图的小问题，尤其是与 NSManagedObject 关系。

另一方面，例如，如果有数据要从网上下载，或者您计划在下一个版本中这样做，则必须有几个上下文，您以后可以将它们结合在一起。为了 UI 性能，您有义务这样做。在这里，您可以选择将上下文从控制器传递到控制器，或者实现某种逻辑，让您在类之间创建和共享相同的上下文。

关键是您一次只能显示一个视图，这与您拥有多少上下文无关。事实上，您可以实现视图中的所有刷新逻辑将出现/消失。

于 2013-09-05T10:08:09.263 回答