objective-c - 使用线程核心数据的现代方式

Question

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

然而，它有点冗长，您必须编写一堆代码才能使其工作。iOS 5 附带了新方法 performBlock: 和 performBlockAndWait:对于 NSManagedObjectContext。现在可以将单个 NSManagedObjectContext 传递给所有线程，并使用 performBlock: 或 performBlockAndWait: 包装所有与 coredata 相关的代码，它应该是更容易也更少头疼，但人们似乎并没有太多谈论这种新方式，甚至 Apple 本身，iOS 文档的“Concurrency with Core Data”一章和“ThreadedCoreData”示例代码仍然推荐一种 NSManagedObjectContext 每个线程。

所以我想知道，performBlock(AndWait): 有什么缺点让人们不使用它吗？还是我说的“新方式”只是一个糟糕的设计？

Answer 1

实际上，每个线程只能有一个 NSManagedObjectContext 仍然是事实。

如果你仔细阅读this :

Private queue (NSPrivateQueueConcurrencyType).

The context creates and manages a private queue. Instead of you creating and managing a thread or queue with which a context is associated, here the context owns the queue and manages all the details for you (provided that you use the block-based methods as described below).

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

因此，您可能会遇到新的 performBlock: 和 performBlockAndWait: 操作使多线程访问核心数据变得更容易的情况(例如，长时间运行的任务获取远程数据和更新数据库)，但最终大局保持不变:每个线程一个上下文。

我认为最好将这一点牢记在心以避免丑陋的意外。

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