В лекции Core Data из Stanford 193P Курс iPhone в iTunes инструктор закодировал образец проекта с основными данными без использования NSPersistentStoreCoordinator и загрузите его с помощью NSManagedObjectModel. Но, глядя на другие образцы кода и книгу Big Nerd Ranch по разработке iPhone, они создают NSManagedObjectModel и PersistentStoreCoordinator и настраивают NSManagedObjectContext таким образом.
Мой вопрос в том, какова цель этого делать так, и каковы плюсы и минусы обоих подходов?
Я внимательно следил за той же лекционной серией. Этот конкретный пример извлекает данные (Фотографы и фотографии) из Flickr и загружает их в CoreData. На самом деле не нужно было использовать CoreData в этом приложении, так как он должен извлекать новые данные из flickr при каждой загрузке приложения, поэтому нет необходимости постоянно сохранять данные. Профессор просто использовал приложение для установки flickr из предыдущей демонстрации в качестве отправной точки, поскольку ученики уже были знакомы с ним (позволяя ему сосредоточиться на объяснении CoreData). Однако, как упоминал рикер, есть огромные преимущества для использования основных данных без сохранения контекста на диск.
Как объяснил Павел в лекции перед демонстрацией, базовую базу данных можно создать (в iOS5) либо с помощью:
Идея первого подхода заключается в том, что Xcode добавит кучу кода в AppDelegate, чтобы настроить каталог документов/постоянный координатор хранилища и модель. Затем он передаст управляемый объект CONTEXT вашему начальному контроллеру представления (который должен иметь свойство NSManagedObjectContext в публичном API), и оттуда вы можете передать контекст, как бутылку пива, когда вы переходите к другим контроллерам view. Передача контекста - правильная процедура для доступа к основной базе данных.
Использование UIManagedDocument очень похоже, за исключением того, что AppDelegate остается в покое. Вы создаете UIManagedDocument (возможно, в вашем исходном контроллере представления), используя URL-адрес из каталога документов приложения (Примечание: вам нужно вручную проверить, уже ли файл выходит, существует, но не открыт или не существует). Затем вы можете использовать этот контекст документа так же, как описано выше.
Другое примечание. Хорошая идея создать указатель на ваш контекст в AppDelegate, чтобы вы могли явно сохранить ваш контекст (только когда он готов!), когда приложение выйдет из строя или завершится.
Координатор постоянных хранилищ настроен автоматически для вас, и вы можете настроить его, используя его свойство persistentStoreOptions (и, действительно, вам нужно будет постоянно сохранять контекст) или путем подкласса UIManagedDocument и переопределения желаемых методов.
Прочитайте обзор в документации UIManagedDocument http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIManagedDocument_Class/Reference/Reference.html
Оба метода работают одинаково и предоставляют вам один и тот же контроль и доступ. С помощью UIManagedDocuments вы можете создавать несколько баз данных в нескольких файлах sqlite, вы также можете дождаться создания/настройки базы данных до ее необходимости. Параметр "Использовать основные данные" предоставляет вам одну базовую базу данных, которую он настраивает при загрузке приложения, позволяет централизовать материал CoreData вокруг AppDelegate, экономит время кодирования и подходит для быстрого отслеживания приложений. Мне нравится UIManagedDocument.
Если вы запустили приложение без опции основных данных и захотели добавить его в AppDelegate, просто создайте новый проект с проверенными данными ядра и скопируйте весь код в AppDelegate (должно быть только 3 свойства и их аксессоры как а также удобный метод доступа к каталогу документов). Вам нужно будет указать ваш начальный контроллер, модель и т.д.
UPDATE: Просто хотел добавить еще одно удобство. Если контекст управляемого объекта хранится в приложении appDelegate, вы можете получить к нему доступ в любом месте своего приложения, просто используя
NSManagedObjectContext* context = [[(AppDelegate*) [UIApplication sharedApplication] delegate] myManagedObjectContext];
это отрицает необходимость передать его.
Для любого приложения CoreData, если вы внесете какие-либо изменения в свою модель, УБЕДИТЕСЬ, ЧТОБЫ УБРАТЬ ПРИЛОЖЕНИЕ В СИМУЛЯТОРЕ, прежде чем строить снова. В противном случае вы получите ошибку в следующей сборке, так как она будет использовать старый файл.
Без постоянного координатора хранилища вы не сможете сохранить свои результаты в постоянной области (база данных, файл и т.д.)... поэтому, если вы хотите, чтобы постоянный диспетчер данных совершенно бесполезен, опустите NSPersistentStoreCoordinator. Вы уверены, что проект не использовал его? Как профессор сохранил данные? Когда вы создаете новый проект Core Data, эта логика автоматически генерируется для вас.
EDIT: я получил его сейчас, профессор использует UIManagedDocument, который использует собственный постоянный координатор хранилища внутри (на основе типа файла), поэтому существует нет необходимости создавать явный (если вы не удовлетворены значением по умолчанию). Итак, в конце концов, это не вопрос о том, использовать ли координатора или нет, так или нет, вы явно его создаете.