是否应该直接使用NSManagedObjects和普通对象？

Question

作为一个好的设计实践，可以安全地开始在应用程序中使用Core Data对象作为模型，并将它们传递给ViewControllers，或者将所有模型保存为NSObjects，并使它们负责创建NSManagedObject并在我们调用save时自行存储他们？

通常的架构是什么，这样可以轻松撤消特定屏幕中的某些内容，如果我突然想将一个正常的NSObject存储到Core Data中？

Answer 1

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

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

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

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

另一方面，例如，如果要从网上下载数据，或者您计划在下一个版本中执行此操作，则必须有多个上下文，您以后将它们连接在一起。对于UI性能，您非常有必要这样做。在这里，您可以选择将上下文从控制器传递到控制器，或者实现某种逻辑，使您可以在类之间创建和共享相同的上下文。

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