Доступ к базовому стеку данных
Эта статья содержит отрывки для создания и доступа к частям основных частей инфраструктуры, определенной Базовой платформой Данных.
Базовая архитектура стека данных
То, как Вы получаете доступ к частям Базового Стека данных, может зависеть частично от архитектуры приложения и платформы.
OS X
Вообще говоря в OS X существует две основных архитектуры приложения для программ, использующих Базовые Данные:
Приложения единственного координатора.
Эти приложения обычно имеют одноядерный Стек данных (как определено единственным персистентным координатором хранилища) управляемый единственным объектом контроллера. Они обычно используют единственное персистентное хранилище для целого приложения.
Основанные на документе приложения.
Эти приложения обычно используют Набор Приложения
NSPersistentDocument
класс. Существует обычно персистентный координатор хранилища и единственное персистентное хранилище, связанное с каждым документом.
Эта статья использует термины “приложение единственного координатора” и “основанное на документе приложение” для дифференциации между этой архитектурой.
iOS
В iOS делегат приложения обычно поддерживает персистентного координатора хранилища, управляющего хранилищем приложения. Это обычно создает контекст управляемого объекта, но этому часто не принадлежит он. Это объяснено более подробно в Получении Контекста Управляемого объекта.
Получение контекста управляемого объекта
В OS X:
В единственном координаторе приложения можно получить контекст приложения непосредственно от делегата приложения.
В основанных на документе приложениях можно получить контекст непосредственно от экземпляра документа.
В iOS:
Условно, Вы получаете контекст от контроллера представления. Необходимо реализовать приложение соответственно, тем не менее, для следования за этим образцом.
Когда Вы реализуете контроллер представления, интегрирующийся с Базовыми Данными, можно добавить
NSManagedObjectContext
свойство.При создании контроллера представления Вы передаете его контекст, который он должен использовать. Вы передаете существующий контекст, или (в ситуации, где Вы хотите, чтобы новый контроллер управлял дискретным набором редактирований), новый контекст, который Вы создаете для него. Это обычно - ответственность делегата приложения создать контекст для передачи первому контроллеру представления, это выведено на экран.
Контроллер представления обычно не должен получать контекст от глобального объекта, такого как делегат приложения — это делает архитектуру приложения твердой. Ни один не должен контроллер представления создавать контекст для своего собственного использования (если это не вложенный контекст). Это может означать, что выполняемое использование операций контекста контроллера не регистрируется в других контекстах, таким образом, контроллеры другого представления будут иметь другие точки зрения на данные.
Иногда, тем не менее, это является проще или более надлежащим получить контекст от где-нибудь кроме приложения или документа или контроллера представления. Несколько объектов, которые Вы могли бы использовать в Базовом Основанном на данных приложении, сохраняют ссылку на контекст управляемого объекта. Сам управляемый объект имеет ссылку на свой собственный контекст, также, как и различные объекты контроллера что Данные Ядра поддержки, такие как массив и объектные контроллеры (NSArrayController
и NSObjectController
в OS X, и NSFetchedResultsController
в iOS).
Получение контекста от одного из этих объектов имеет преимущество, что, если Вы повторно проектируете свое приложение, например для использования многократных контекстов, код, вероятно, останется допустимым. Например, если у Вас есть управляемый объект, и Вы хотите создать новый управляемый объект, который будет связан с ним, можно попросить у исходного объекта его контекста управляемого объекта и создать новый объект с помощью этого. Это гарантирует, что новый объект, который Вы создаете, находится в том же контексте как оригинал.
Создание нового контекста управляемого объекта
Иногда необходимо создавать новый контекст управляемого объекта для содержания непересекающегося набора редактирований, которые Вы могли бы хотеть отбросить, не тревожа основной контекст (например, при представлении модального представления, чтобы добавить и отредактировать новый объект).
Для создания нового контекста управляемого объекта Вам нужен персистентный координатор хранилища.
NSPersistentStoreCoordinator *psc = <#Get the coordinator#>; |
NSManagedObjectContext *newContext = [[NSManagedObjectContext alloc] init]; |
[newContext setPersistentStoreCoordinator:psc]; |
Если у Вас уже есть ссылка на существующий контекст, можно попросить у него его персистентного координатора хранилища. Таким образом, можно быть уверены, что новый контекст использует того же координатора в качестве существующего (предполагающий, что это - намерение):
NSManagedObjectContext *context = <#Get the context#>; |
NSPersistentStoreCoordinator *psc = [context persistentStoreCoordinator]; |
NSManagedObjectContext *newContext = [[NSManagedObjectContext alloc] init]; |
[newContext setPersistentStoreCoordinator:psc]; |
Получение модели управляемого объекта и объектов
Иногда необходимо получать доступ к модели управляемого объекта для получения информации об определенном объекте.
Приложения обычно имеют просто единственную модель (несмотря на то, что она может иметь больше чем одну конфигурацию). В приложении единственного координатора Вы обычно получаете модель непосредственно от делегата приложения. В основанном на документе приложении Вы получаете модель непосредственно из документа.
Если у Вас есть доступ к контексту управляемого объекта — прямо или косвенно (см. Получение Контекста Управляемого объекта) — можно получить модель от персистентного координатора хранилища контекста. От модели можно получить использование объекта entitiesByName
:
NSManagedObjectContext *context = <#Get the context#>; |
NSPersistentStoreCoordinator *psc = [context persistentStoreCoordinator]; |
NSManagedObjectModel *model = [psc managedObjectModel]; |
NSEntityDescription *entity = [[model entitiesByName] objectForKey:@"<#Entity name#>"]; |
Добавление персистентного хранилища
Во многих приложениях существует только одно персистентное хранилище для каждого персистентного координатора хранилища. В приложении единственного координатора хранилище связано с целым приложением. В основанном на документе приложении каждый документ имеет отдельное хранилище. Иногда, однако, Вы могли бы хотеть добавить другое хранилище. Вы добавляете хранилище к персистентному координатору хранилища. Необходимо указать тип хранилища, расположение и конфигурацию (на основе настоящего конфигураций на модели управляемого объекта, связанной с координатором). Можно также указать другие опции, такой как, должна ли старая версия хранилища быть перемещена на текущую версию (см. Базовое Руководство по программированию Управления версиями и Миграции данных Модели данных).
В единственном координаторе приложения можно получить координатора приложения непосредственно от делегата приложения.
В основанных на документе приложениях можно получить координатора от контекста управляемого объекта документа.
NSPersistentStoreCoordinator *psc = <#Get the coordinator#>; |
NSURL *storeUrl = [NSURL fileURLWithPath:@"<#Path to store#>"]; |
NSString *storeType = <#Store type#>; // A store type, such as NSSQLiteStoreType |
NSError *error; |
if (![psc addPersistentStoreWithType:storeType configuration:nil |
URL:storeUrl options:nil error:&error]) { |
// Handle the error. |
} |