我的应用程序中只有一个数据库模型架构,因此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.
}
所以,问题是,在主应用程序委托中保留persistentStoreCoordinator和managedObjectModel方法(并通过应用程序访问它们)是合理的,但是将managedObjectContext方法移动到需要私有数据处理的那些类?
答案 0 :(得分:2)
您总是会在主线程上运行一个主要的托管对象上下文。
如果你正在另一个线程上进行后台处理,你可以在后台线程上创建另一个NSManagedObjectContext,指向相同的NSPersistentStoreCoordinator。
在后台上下文中保存/删除/更新时,会在主线程上触发通知,并将更改合并回主上下文。
就个人而言,我在App Delegate中没有任何Core Data对象,因为我不认为它们属于那里。我认为Apple在他们的例子中使用它来简化示例。我通常有一个CoreDataStack对象,它在我需要的地方传递。
您可以查看更高级别的Core Data API,例如Magical Record。我刚开始使用它,它非常有用,并删除了从Core Data获得的许多样板代码。它由Marcus Zarra和团队撰写,他显然对Core Data非常了解。
在iOS 5中,通过允许ManagedObjectContexts拥有父上下文来改进Core数据。因此,在您的情况下,您的背景上下文将是父上下文的子项,并且显然合并更容易。但我还没有尝试过。