将“每线程1 moc”策略与“子moc”策略混合是否有效？

Question

直到现在，我一直对主线程使用"main moc“，初始化如下：

[[NSManagedObjectContext alloc] init];

然后，我有了NSOperation子类和它们自己的moc，它们从webservice导入数据，我在保存NSManagedObjectContextDidSaveNotification时合并到“主”moc中，但是现在我需要添加“临时”对象的能力，用户以后可以提交(或者不提交)。因此，看起来子上下文非常合适，为了使用子上下文，我将“主moc”的初始化更改为

 [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];

问题是:如果与子上下文策略一起使用，我的NSOperation子类的当前结构(初始化时没有自己的线程中的类型)会有问题吗？我不这么认为，但我不觉得混合这些策略有多大作用。

请注意，我希望维护NSOperation子类，并且不希望也使用子上下文导入数据，因为它在性能上受到影响，请参见http://floriankugler.com/blog/2013/4/29/concurrent-core-data-stack-performance-shootout

此外，当我为我的主线程(即NSMainQueueConcurrencyType类型)创建一个新的子线程时，我是否可以用NSMainQueueConcurrencyType类型创建这个子线程，并像往常一样在主线程中继续使用我的对象？还是我被迫使用NSPrivateQueueConcurrencyType，并对我的对象上的每个操作使用performBlock:？我之所以问这个问题，是因为文档中不清楚在同一个线程上使用2moc(本例中的主线程)是否会出现问题。

UPDATE：最后，我在生产上实现并使用了这个解决方案，到目前为止还没有出现问题。当moc有一个NSManagedObjectContextDidSaveNotification时，我唯一需要做的就是避免在parentContext通知中合并(我们不想将mocs与父上下文合并，因为它们自己管理合并，但是很明显，这种moc上的save也会触发通知)

Answer 1

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

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

Answer 2

实际上，这是在处理多个线程时表示的。在这里，我写了一个关于这一点的文章。其中提到的从mocs正是为处理操作而设计的，每个操作都是在它自己的从moc上进行的。