拥有多个 NSPersistentStoreCoordinator 有意义吗？

Posted 2023-03-12

【中文标题】拥有多个 NSPersistentStoreCoordinator 有意义吗？

【英文标题】：Does it make sense to have multiple NSPersistentStoreCoordinators?

【发布时间】：2011-06-18 04:56:55

【问题描述】：

我是 Core Data 的新手，我正在努力确保我的数据模型及其使用设置正确。

我的应用程序中基本上有两种文件类型...一种包含设置类型数据，另一种包含用户将使用的数据集（有点像文档，尽管我可以想象用户在 10 秒甚至更长时间内工作100 个这样的文件）。

我一直在阅读有关 Core Data 的书籍，我记得读过通常一个应用程序只有一个 NSPersistentStoreCoordinator、一个 NSManagedObjectContext 和一个 NSManagedObjectModel。

我目前有一个托管对象模型，其中包含我拥有的各种文件类型的配置。我一直计划同时拥有NSPersistentStoreCoordinators / NSManagedObjectContexts 之一，当我创建新的 Core Data 对象时，我会确保将每个对象都添加到正确的持久存储中。

但是，我已经看到每个文件都有自己的 NSPersistentStoreCoordinator 和 NSManagedObjectContext 的示例。

在单线程应用程序中拥有多个NSPersistentStoreCoordinators 和NSManagedObjectContexts 有优缺点吗？

最初，我一直希望能够在用户剪切和粘贴类型编辑期间将对象从一个持久存储移动到另一个，但这似乎都不可能。

非常感谢任何建议！

编辑

这里有一些关于什么让我感到困惑的更多信息。当我阅读有关 NSPersistentStoreCoordinator 的文档时，它说：

协调器旨在呈现 托管对象的外观 上下文这样的一组 持久存储显示为 聚合商店。

就我而言，这不是我想要的。我希望我的文档被视为单独的文档，并且我不希望查询相互混淆。

此外，只有一个持久存储协调器和许多持久存储，如果我忘记在创建时将实体分配给正确的存储，我会发现自己遇到错误，因为实体在创建时被任意分配给有效存储。我不确定指向不同商店中对象的关系会发生什么（可能是断言失败？）。

对我来说，似乎每个商店都有一个上下文/持久存储协调器不太容易出现错误，并且允许我将每个文档的数据彼此隔离。

单个持久性商店似乎给我买的唯一东西是我可以同时为所有商店执行保存操作，这将是可取的。对于多个上下文/存储协调器，我需要执行单独的保存操作。

如果您使用 OSX NSPersistentDocument 类，它似乎对每个文档强制执行单独的上下文/存储协调器。

无论如何，从我的所有研究来看，似乎单独的商店协调器/上下文对我的应用程序更有效，但我发布此内容的原因是因为我是 Core Data 的新手，而且这种方法似乎与推荐的流程背道而驰我担心我错过了一些会回来咬我的陷阱。

更多想法/信息

随着我更多地思考这个问题并阅读更多其他人的反馈（谢谢大家！！！），我目前的想法如下。

就我自己而言，这两种方法之间似乎并没有太大区别，我目前相信无论哪种方式我都可以让它运作良好。

使用单个商店协调器，我需要确保新创建的实体附加到正确的商店（这没什么大不了的）。对于多个商店协调员，我需要确保将新创建的实体添加到正确的上下文中（其中我会有很多）。就我的代码结构而言，任何一种方法对我来说都应该相对容易。

我个人希望一次搜索一家商店。如果我有多个商店协调员，这是自动的。如果我只有一个商店协调员，我需要确保限制获取请求。 （不管怎样，没什么大不了的）。

商店协调器的文档暗示它的优点是使多个商店看起来像一个。对于我的应用程序，我不需要或不希望这样做，所以这对我来说不是一个真正的考虑因素（尽管如果我想在未来添加跨商店搜索功能，最好将所有内容保存在一个商店协调器中）。

对我来说，以上任何一个理由都不是很好的论据，如果它们是唯一的论据，我可能会尝试以更传统的方式做事并坚持单一的商店协调员。

然而，最后一个原因（也是我最初发布此问题的主要原因）是我计划利用 ios 5 中似乎需要多个商店协调员的一些功能。我希望能够弱链接我的应用程序以向后兼容，因此我的 iOS 4 代码似乎与 iOS 5 代码非常相似。

我想得越多，由于支持多个操作系统版本，我可能仍然可以通过正确的抽象来实现任何一种方式。

感谢大家的反馈！我正在慢慢掌握 Core Data 的窍门，这主要是一次很棒的体验，尽管它也让我感到头疼！

【问题讨论】：

如果您可以“重构”您的问题，使其更笼统（即，与 iOS 5 无关），那么您有望得到答案。在那之前，正如@Caleb 提到的，iOS 5 处于保密协议之下，我们不会回答这个问题。如果您需要了解它在 iOS 5 中的工作原理，请在devforums.apple.com 上提问。

你说得对...我重新措辞了我的问题（无论如何我的问题与 iOS 5 没有任何关系）。

【参考方案1】：

一般来说，一个应用只使用一个 PersistentStoreCoordinator，它在应用委托中初始化。

有关更多详细信息和说明，请查看Core Data上的苹果文档

【讨论】：

感谢您提供指向文档的指针。但是，我已经阅读了整个文档。我还阅读了 Marcus Zarra 的“Core Data”一书以及 Michael Privat / Robert Warner 的“Pro Core Data for iOS”。它们都是好书，尽管它们仍然没有回答我上面的问题。我读过一个应用程序应该只有一个 PersistentStoreCoordinator，尽管我仍然不确定它是否最适合我的需求。请参阅我上面的说明。

【参考方案2】：

老实说，我想不出为什么要拥有第二个协调器的原因，除非您在同一模型上执行一些非常严重的并发、多线程任务。根据您上面的描述，您可能只需要为某些托管对象创建单独的上下文，或者如果您需要它们完全独立，则可能需要单独的存储。

您几乎不会直接与持久存储协调器交互，因为您的大部分操作都是在上下文级别完成的，然后在您准备好时（再次通过上下文）通过存储协调器进行持久化。

您显然已经完成了自己的研究，所以我不会告诉您检查文档 XYZ（核心数据对于基本级别的东西都有很好的文档记录，但任何更高级的东西都需要您自己完成），但我的主要观点是否为这些模型中的每一个设置单独的商店协调员可能会增加代码的复杂性，而不是使其更易于管理，这似乎是您在原始问题中的主要动机。

【参考方案3】：

我认为在您的应用中拥有多个 NSPersistentStoreCoordinator 实例没有任何真正的技术限制，只要它们都指向磁盘上的唯一位置。

但是，采用这种方法绝对不常见，并且会为您的应用增加很多可能不必要的复杂性。根据您对数据模型的描述，我看不出您需要多个 NSPersistentStoreCoordinators 的任何理由。

请务必阅读 CoreData 编程指南，并知道您需要为每个线程创建一个唯一的 NSManagedObjectContext，而不是您在问题中描述的每个 NSPersistentStoreCoordinator。

【讨论】：

保罗...感谢 cmets！我对您关于每个线程需要一个上下文的评论有点困惑。如果我有多个商店协调员，我是否也需要多个上下文？另外，我不确定为什么做我上面所说的会增加复杂性？在某些方面（请参阅上面的编辑），它似乎降低了我的复杂性（我不必担心确保在正确的商店中创建实体，以及如何限制查询仅从商店中提取实体我正在尝试搜索）。

是的，对不起，如果我的措辞令人困惑。如果您有多个 NSPSC（NSPersistentStoreCoordinator's），则您的应用程序中的每个 NSPSC 和每个线程都需要一个 NSMOC。这增加了复杂性，因为您需要小心地构建您的应用程序，这样您就可以确保您始终在正确的存储和上下文中写入/读取。我也很困惑为什么您担心每个文档/实体有单独的商店。使用经过深思熟虑的数据模型，这应该不是问题。你还有什么可以分享的，是什么让你觉得你需要它？

Paul ...再次感谢您的见解！我不太担心管理存储和上下文的复杂性，因为我的文件被包装在它们自己的类中，它将管理所有对象的创建和删除。我只是在上面添加了一些想法，希望能进一步解释我的推理。