应该直接将 NSManagedObjects 与普通对象一起使用吗？答案

【问题标题】：Should one directly use NSManagedObjects long with normal objects?应该直接将 NSManagedObjects 与普通对象一起使用吗？
【发布时间】：2013-09-05 09:54:49
【问题描述】：

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

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

【问题讨论】：

标签： ios core-data

【解决方案1】：

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

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

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

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

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

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

【讨论】：

那么理想情况下你保留多少个 managedObjectContexts ？如果我有一个 VC，我进行了一些更改，然后去其他一些 VC 进行了一些更改，现在我想通过按该屏幕上的撤消按钮来撤消我的更改，但这件事会撤消我在我之间所做的更改转到其他屏幕？如果我直接使用 Core Data 对象，我该如何解决这些问题