CoreData 设计模式：我应该拥有多个或多少个 NSPessistentObjectContexts 的单个对象？

Posted 2023-03-04

【中文标题】CoreData 设计模式：我应该拥有多个或多少个 NSPessistentObjectContexts 的单个对象？

【英文标题】：CoreData design pattern: persisting a single object of many -or-how many NSPessistentObjectContexts should I have?

【发布时间】：2009-06-08 14:21:21

【问题描述】：

我正在将应用程序从 SQLitePersistentObjects 转换为 CoreData。

在应用程序中，有一个类，我从从我的服务器检索的 XML 文件生成许多*实例。 UI 可以触发需要我保存一些*这些对象的操作，直到下次调用应用程序。

除了每个对象都有一个 NSManagedObjectContext （仅与它们的从属对象共享，其中可以包括 blob）。我看不到如何对哪些对象进行持久化进行细粒度控制（即在对象级别）。如果我尝试为所有新创建的对象设置一个上下文，当我尝试将我的一个对象移动到新上下文时会出现异常，以便我可以自己持久保存它。我猜这是因为它拥有的对象留在“旧”上下文中。

我看到的另一个选项是拥有一个上下文，保留我的所有对象，然后删除我以后不需要的那些 - 这感觉它会过多地访问数据库，但也许 CoreData 有魔力。

所以：

我是否遗漏了有关我的 CoreData 应用程序架构方式的一些基本信息？ 每个对象都有一个上下文是一种好的设计模式吗？ 有没有更好的方法在上下文之间移动对象以避免 2？

* 其中“many”的意思是“几十个，可能是几百个，而不是几千个”，“some”至少比“many”小一个数量级

还有cross posted to the Apple forums。

【参考方案1】：

Core Data 实际上并不是一个对象持久化框架。它是一个对象图管理框架，恰好能够将该图保存到磁盘（有关更多信息，请参阅this 先前的 SO 答案）。因此，尝试使用 Core Data 仅保留对象图中的 一些 对象将是违背规律的。 Core Data 更愿意管理您将要创建的所有对象的整个图表。所以，这些选项并不完美，但我看到了几个（包括你提到的一些）：

您可以在 Core Data 上下文中创建所有对象，然后删除您不想保存的对象。在您保存上下文之前，所有内容都在内存中，因此不会像您建议的那样“返回数据库”。即使在保存到磁盘之后，Core Data 也非常擅长在上下文的行缓存中缓存实例，并且只需让它做自己的事情而不必担心磁盘上的内容和内存中的内容，开销非常小。 如果您可以先创建所有对象，然后在决定保存哪些对象之前在内存中进行所有处理，您可以创建一个带有持久存储协调器的单个 NSManagedObjectContext，该协调器只有一个内存持久存储。当您决定要保存哪些对象时，您可以将持久（XML/二进制/SQLite）存储添加到持久存储协调器，将要保存的对象分配到该存储（使用上下文的(void)assignObject:(id)object toPersistentStore:(NSPersistentStore *)store），然后保存上下文。 您可以在 Core Data 之外创建所有对象，然后将要保存的对象复制到 Core Data 上下文中。 您可以在单个内存上下文中创建所有对象，并编写自己的方法将这些对象的属性和关系复制到新上下文中，从而仅保存所需的实例。除非模型中的实体有很多关系，否则这并不难（请参阅this 页面，了解有关使用多通道方法将对象从一个存储迁移到另一个存储的提示；它在版本控制管理的上下文中描述了该技术对象模型，并且在 10.5 中不再需要用于该目的，但该技术也适用于您的用例）。

就个人而言，我会选择选项 1——让 Core Data 做它的事情，包括管理从你的对象图中删除。

【讨论】：

谢谢巴里，经过几个令人沮丧的研究后，我自己得出了这个结论，但是让真正知道他们在说什么的人确认它非常有用。

不用担心。我们都站在巨人的肩膀上。祝你好运。

我可以确认 1. 运行良好。我已经实现了一个复杂的应用程序，其中包含大约 25 种不同的实体类型，它们代表从服务器传递给我的相互关联的对象。如果服务器对象具有类型层次结构，则使用 Core Data 中的子实体进行模仿。