我对 Core Data 还是很陌生，我正在尝试理解为什么它需要传递 NSManagedObjectContext。据我了解，需要传递上下文，这样多个线程才不会影响相同的上下文，但我也觉得这种模式有时被认为是一种反模式，如前所述 here .
Core Data 理论上能否以线程安全的方式实现，从而避免使用这种模式？其他 ORM(例如 Ruby 的 ActiveRecord)如何避免这种模式？例如，CoreData 不能实现一个 per-NSManagedObject 保存方法，例如 extension .这个轻型框架不处理多线程，但 NSManagedObjects 不能使用某种内部 GCD 队列来支持它，而内部上下文不公开吗？
抱歉，如果我遗漏了任何重要内容。
最佳答案
NSManagedObjectContext 是应用程序对象图的内存容器，就像持久存储(XML、SQLite 等)通常代表对象图的磁盘容器一样。
这种方法有一些优点:
- 故障可以应用于一组对象，或者在 CoreData 的情况下应用于整个对象图
- 这是一个方便的抽象，用于强制应用程序对其 I/O 进行批处理。
- 它提供了一个单一的联系点，可以有效地对整个对象图(NSFetchRequests 等)执行操作
- 撤消可以应用于对象图，而不仅仅是单个对象。
同样重要的是要记住 CoreData 不是 ORM 框架，它是对象持久性框架。 CoreData 的主要职责是更有效地访问以持久格式存储在磁盘上的数据。但是，它不会尝试模拟关系数据库的功能。
关于并发，即将发布的 Mac OSX 中引入了新的并发模型。您可以在 developer.apple.com 上阅读更多相关信息。
虽然在抽象中，为托管对象上下文选择的并发模型更多地与单个应用程序的细节有关，而不是上下文模式本身。 NSManagedObjectContext 的实例通常不应该在线程之间共享。
就像每个线程都需要它自己的 NSAutoReleasePool 实例一样，每个线程也应该有它自己的 MOC。这样，当线程完成执行时，它可以将其更改提交到磁盘上的存储区，然后释放上下文，释放线程上处理的对象消耗的所有内存。
与允许单个上下文在给定应用程序的生命周期内持续消耗系统资源相比，这是一种更有效的范例。当然，这也可以通过在上下文中调用 -reset 来完成，这将导致上下文使用的所有 NSManagedObject 返回错误。
关于objective-c - 上下文模式？为什么 Core Data 需要它？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6469892/