使用线程coredata的现代方法

Question

在过去，我们使用coredata作为Apple ask，每个线程一个NSManagedObjectContext，使用NSNotificationCenter观察NSManagedObjectContextDidSaveNotification，然后合并更改。 Apple向我们展示了正确的方式sample code。

然而，它有点冗长，你必须写一堆代码才能使它工作.iOS 5附带了新方法performBlock:和performBlockAndWait: NSManagedObjectContext。现在可以将单个NSManagedObjectContext传递给所有线程，并使用performBlock:或performBlockAndWait:来包装所有与coredata相关的代码，它应该更容易，更少头痛，但人们似乎做了要谈论这种新方法，即使是Apple本身，iOS文档中的“并发核心数据”一章和“ThreadedCoreData”示例代码仍然建议每个线程使用一个NSManagedObjectContext。

所以我想知道，performBlock(AndWait):是否有任何不利因素让人们不使用它？或者我说的“新方式”只是一个糟糕的设计？

Answer 1

实际上，每个线程只能有一个NSManagedObjectContext。

如果您仔细阅读this：

  

专用队列（NSPrivateQueueConcurrencyType）。

     

上下文创建并管理专用队列。您不是创建和管理与上下文关联的线程或队列，而是在此拥有队列并为您管理所有详细信息（前提是您使用如下所述的基于块的方法）。

这意味着NSPrivateQueueConcurrencyType上下文也为您处理操作队列，但您无法在不同线程之间共享该上下文。 如果您需要从UI访问上下文，这将需要具有NSMainQueueConcurrencyType类型的第二个上下文，这一点尤其重要。

因此，您可能会遇到新的performBlock:和performBlockAndWait:操作使得对多核线程数据的多线程访问变得更容易的情况（例如，长时间运行的任务获取远程数据并更新数据库），但最终，大局仍然是相同的：每个线程一个上下文。

我认为最好记住这一点，以避免丑陋的惊喜。

对于合并更改，您可以将NSManagedObjectContextDidSaveNotification与旧约束模型一起使用（您处理线程或操作队列），或者您可以使用较新的父子关系，其中saveContext推送从子上下文更改为父上下文。 （感谢flexaddicted关于父子情境的评论）。

Answer 2

  

现在可以将单个NSManagedObjectContext传递给所有线程，并使用performBlock:或performBlockAndWait:来包装所有与coredata相关的

这是什么意思？除了其他方面，新的核心数据的目标是创建一个父子关系，其中客户端级别的更改可以很容易地直接提取给父级。 每个帖子都有自己的上下文。显然，NSManagedObject的限制仍然存在。当您需要在线程之间共享对象时，您需要共享它们NSManagedObjectID s。

与先前方法的不同之处在于performBlock（及其同步版本）允许您不必担心线程环境。使用它们来做事情，Core Data将为您管理事情。

关于您的问题，例如，我不会在旧的Core Data项目中使用新内容，因为它们需要进行代码重组。显然，这严格取决于项目的规模。但是如果你开始一个新项目，你应该尝试一下。他们非常具有挑战性！