Question

到目前为止，我总是在主线程中使用“main moc”，初始化如下：

[[NSManagedObjectContext alloc] init];

然后我有NSOperation个子类，他们自己的moc从webservice导入数据，我合并在“main”moc上保存观察NSManagedObjectContextDidSaveNotification 但是现在我需要能够添加用户以后可以提交（或不提交）的“临时”对象。所以它看起来像子上下文是完美的契合，并且为了使用子上下文我改变了我的“主moc”的初始化为

 [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];

问题是：如果与子上下文策略一起使用，我的当前具有NSOperation子类的子结构是否具有自己的moc（在自己的线程中没有类型的情况下初始化）会有问题吗？我不这么认为，但我没有太多关于混合这些策略的内容。

请注意，我想维护NSOperation子类，我也不想使用子上下文来导入我的数据，因为它会影响性能，请参阅http://floriankugler.com/blog/2013/4/29/concurrent-core-data-stack-performance-shootout

此外，当我创建一个主线程的新子项（类型为NSMainQueueConcurrencyType）时，我可以创建类型为NSMainQueueConcurrencyType的子项，继续使用主体中的对象线程像往常一样？或者我被迫使用NSPrivateQueueConcurrencyType，并对我的对象上的每个操作使用performBlock:？我问，因为如果在同一个线程上使用2 moc（在这种情况下是主线程）可能是个问题，那么从文档中就不清楚了。

更新：最后，我在生产中实施并使用了这个解决方案，到目前为止还没有问题。我需要做的唯一事情就是避免在moc有NSManagedObjectContextDidSaveNotification时我的parentContext通知合并（我们不想将moc与父上下文合并，因为他们自己管理合并，但很明显，此类moc上的save也会触发通知

Answer 1

是的，您可以拥有多个主队列上下文moc，正是您所说的 - 您创建了一个临时编辑上下文，用于编辑数据，然后根据用户操作保存或丢弃。

至于与操作队列上下文的混合和匹配 - 这应该不是问题。如果您要合并回父上下文，那么任何子上下文都会在下次获取时获取该数据。

Answer 2

实际上，在使用多个线程时表明了这一点。在这里，我已经写了一篇article。其中提到的奴隶mocs的设计完全是为了处理操作，每个操作都在它自己的奴隶moc上。

将“每个线程1 moc”策略与“child moc”策略混合起来是否有效？

2 个答案: