我的应用程序中只有一个数据库模型架构，因此IMHO，NSManagedObjectModel和NSPersistentStoreCoordinator对象可能驻留在主应用程序委托类中，以便从应用程序的其他部分进行访问。但是，我想为我的应用程序的各个部分使用不同的NSManagedObjectContexts对象，因为我将使用多线程。
根据我个人数据库的经验，我认为NSManagedObjectContext在某种程度上类似于数据库事务的概念。因此，为避免我的应用程序的各个多线程部分具有单独的上下文对象是合乎逻辑的，以避免将不必要的更改从一个应用程序部分提交到另一个应用程序部分。当创建启用了核心数据的新项目时，Xcode在主应用程序委托中创建三个基本方法
- (NSManagedObjectModel *)managedObjectModel{
// reads your database model file and defined entities from defined DataSchema.xcdatamodeld file
}
- (NSPersistentStoreCoordinator *)persistentStoreCoordinator{
// uses already read database model and initializes defined sqlite database file and returns a persistent store coordinator - a pointer to the database
}
- (NSManagedObjectContext *)managedObjectContext{
// opens a connection (and transaction) to the database.
}
因此，问题是，在主应用程序委托中保留persistentStoreStoreCoordinator和managedObjectModel方法（并通过应用程序访问它们），但将managedObjectContext方法移至需要私有数据处理的类是否合理？
最佳答案
您总是会有一个在主线程上运行的主托管对象上下文。
如果要在另一个线程上进行后台处理，则可以在一个后台线程上创建另一个NSManagedObjectContext，指向同一NSPersistentStoreCoordinator。
在后台上下文中保存/删除/更新时，将触发通知，通知您在主线程上侦听，并将更改合并回主上下文。
就我个人而言，我在应用程序委托中没有任何核心数据对象，因为我认为它们不属于那里。我认为Apple在其示例中使用了该示例，以简化示例。我通常会在需要的地方传递一个CoreDataStack对象。
您可以查看更高级别的Core Data API，例如Magical Record。我刚刚开始使用它，它非常有用，并且删除了您从Core Data获得的许多样板代码。它是由Marcus Zarra和他的团队写的，他显然对Core Data了解很多。
在iOS 5中，通过允许ManagedObjectContexts具有父上下文来改进了核心数据。因此，在您的情况下，您的背景上下文将是父上下文的子级，显然合并起来要容易得多。尽管如此，我还没有尝试过。
关于objective-c - 如何拥有不同的NSManagedObjectContext？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9925568/