我对核心数据还是相当陌生的，我正在努力理解为什么它需要传递NSManagedObjectContext。据我所知，传递上下文是必要的，这样多个线程就不会影响同一个上下文，但我也有这样的印象，即这种模式有时被认为是反模式，正如这里所指出的。
从理论上讲，核心数据可以以线程安全的方式实现，从而避免使用这种模式吗？其他ORM（例如Ruby的ActiveRecord）如何避免这种模式？例如，CoreData无法实现像此扩展中那样的每个NSManagedObject的保存方法。这个轻量级框架不处理多线程，但NSManagedObjects不能使用某种内部GCD队列来支持它吗？
如果我遗漏了什么重要的东西，我很抱歉。
NSManagedObjectContext是应用程序对象图的内存容器，就像持久存储（XML、SQLite等）通常表示对象图的磁盘容器一样。
这种方法有一些优点：
- 故障可以应用于一组对象，或者在CoreData的情况下应用于整个对象图
- 这是一个方便的抽象，用于强制应用程序对其I/O进行批处理
- 它提供了一个单一的联系点，用于在整个对象图（NSFetchRequests等）上高效地执行操作
- 撤消可以应用于对象图，而不仅仅是单个对象
同样重要的是要记住，CoreData不是一个ORM框架，它是一个对象持久性框架。CoreData的主要职责是提高访问以持久格式存储在磁盘上的数据的效率。然而，它并没有试图模仿关系数据库的功能。
关于并发性，在即将发布的MacOSX中引入了新的并发模型。你可以在developer.apple.com.上了解更多信息
不过，抽象地说，为托管对象上下文选择的并发模型更多地与单个应用程序的细节有关，而不是上下文模式本身。NSManagedObjectContext的实例通常不应在线程之间共享。
就像每个线程都需要自己的NSAutoReleasePool实例一样，每个线程也应该有自己的MOC。这样，当线程执行完毕时，它可以将更改提交到磁盘上的存储区，然后释放上下文，释放线程上处理的对象所消耗的所有内存。
这是一个比允许单个上下文在给定应用程序的生命周期中持续消耗系统资源更有效的范例。当然，这也可以通过在上下文上调用-reset来完成，这将导致上下文使用的所有NSManagedObject都返回到错误中。
每个线程需要一个NSManagedObjectContext。因此，您将在主线程上使用一个来填充UI，对于较长的操作，您将为每个后台线程使用另一个。如果您希望从其他线程中合并结果，那么您可以订阅一个通知，该通知可以快速将更改的内容合并到主MOC中。