0

在过去，我们按照Apple 的要求使用 coredata ，NSManagedObjectContext每个线程一个，用于NSNotificationCenter观察NSManagedObjectContextDidSaveNotification，然后将更改合并回来。Apple 在其示例代码中向我们展示了正确的方式。

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

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

4

2 回答 2

2

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

如果您仔细阅读此内容：

专用队列 (NSPrivateQueueConcurrencyType)。

上下文创建和管理私有队列。您无需创建和管理与上下文关联的线程或队列，而是在这里上下文拥有队列并为您管理所有细节（前提是您使用如下所述的基于块的方法）。

这意味着NSPrivateQueueConcurrencyType上下文还为您处理操作队列，但您不能在不同线程之间共享该上下文。如果您需要从 UI 访问上下文，这尤其相关，这需要第二个 type 上下文NSMainQueueConcurrencyType。

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

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

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

于 2013-01-08T09:08:54.743 回答
0

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

你这是什么意思？新的 Core Data 东西的目标，除其他外，它是创建一个父子关系，其中客户端级别的更改可以轻松地直接拉到父级。每个线程都有自己的上下文。显然，关于NSManagedObjects 的限制仍然存在。当你需要在线程之间共享对象时，你需要共享它们NSManagedObjectID的s。

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

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

于 2013-01-08T09:20:23.220 回答