Как иметь разные NSManagedObjectContexts?

Question

В моем приложении только одна схема модели базы данных, поэтому объекты 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 в те классы, которым требуется обработка личных данных?

Answer 1

У вас всегда будет один основной контекст управляемого объекта, который выполняется в главном потоке.

Если вы выполняете фоновую обработку в другом потоке, вы можете создать еще один NSManagedObjectContext в фоновом потоке, указывая на тот же NSPersistentStoreCoordinator.

Когда вы сохраняете / удаляете / обновляете в фоновом контексте, запускаются уведомления, которые вы слушаете в главном потоке, и объединяете изменения обратно в основной контекст.

Лично у меня нет объектов Core Data в App Delegate, потому что я не думаю, что они принадлежат там. Я думаю, что Apple использует это в своих примерах для простоты примера. У меня обычно есть объект CoreDataStack, который передается туда, где он мне нужен.

Вы можете взглянуть на API-интерфейс Core Data более высокого уровня, такой как Magical Record. Я только начал использовать это, и это довольно полезно, и удаляет много стандартного кода, который вы получаете из Core Data. Он написан Маркусом Заррой и командой, парнем, который, очевидно, много знает о базовых данных.

В iOS 5 данные Core были улучшены благодаря тому, что ManagedObjectContexts имел родительский контекст. Так что в вашем случае ваши фоновые контексты будут дочерними по отношению к родительскому контексту, и, очевидно, слить обратно гораздо проще. Хотя я еще не пробовал.

Answer 2

Итак, логично иметь отдельные объекты контекста для различных многопоточные части моего приложения, чтобы избежать совершения нежелательных переход от одной части приложения к другой.

Возможно иметь несколько контекстов, что широко используется.

разумно ли оставить persistentStoreCoordinator и методы managedObjectModel в делегате основного приложения (и доступ к ним через приложение), но переместить метод managedObjectContext к этим классы, которые требуют частной обработки данных?

• Вы можете оставить его в делегате приложения, получив к нему доступ через [[UIApplication sharedApplication] delegate].
• Вы можете создать отдельный одноэлементный класс, содержащий базовый стек данных.
• Вы можете просто передать указатель на managedObjectContext между классами.
• Каждый viewController может создать свой собственный контекст, связывающий его с родительским контекстом через setParentContext:.

Как видите, это действительно зависит от сложности вашего проекта. Как правило, если у вас есть много конкретных поисков и сохранений, вы можете захотеть вставить стек основных данных в его собственный класс. Для небольших проектов почему бы просто не оставить его в делегате приложения и передать контекст через указатель.

Также ознакомьтесь с сеансом WWDC 2011 года о базовых данных. В нем говорится о куче интересных новых функций.