Где разместить «Core Data Stack» в приложении Cocoa / Cocoa Touch

В шаблоне данных ядра iPhone Apple помещает основной стек данных в делегат приложения.

Однако моя первоначальная наклонность заключается в том, чтобы переместить этот код в собственный class, чья ответственность заключается в обработке управления базовым стеком данных.

Обычно вы инкапсулируете эту функциональность в свой class или вы оставите ее в App Delegate?

Резюме. Нет необходимости создавать singleton для управления стекю Core Data; действительно, это, скорее всего, будет контрпродуктивным.

Стек Core Data создается делегатом приложения. Важно отметить, однако, как показывают все примеры, стек (в основном контекст управляемого объекта) не извлекается непосредственно из стека (*). Вместо этого контекст передается на первый controller представления, а из них в контекст или управляемый объект передается от одного controllerа представления к следующему (как описано в разделе «Доступ к базовому стеку данных» ). Это следует за базовой моделью для iPhone всех приложений: вы передаете данные или controller модели с одного controllerа представления на другой.

Типичная роль синглтона, как описано здесь, является модельным controllerом. С помощью Core Data контекст управляемых объектов уже является модельным controllerом. Это также дает вам возможность доступа к другим частям стека, если это необходимо. Более того, в некоторых ситуациях (как описано в документации) вы можете использовать другой контекст для выполнения дискретного набора действий. Соответствующая единица валюты для controllerа вида, следовательно, обычно является контекстом управляемого объекта, в противном случае управляемым объектом. Использование и передача объекта singleton, который управляет стеком (и из которого вы извлекаете контекст), как правило, в лучшем случае вводит ненужный уровень косвенности и в худшем случае вводит излишнюю жесткость приложения.

(*) Ни один пример не извлекает контекст, используя:

[[UIApplication delegate] managedObjectContext]; 

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

Я оставляю логику основных данных в делегате приложения по следующим причинам:

1) Я не вижу никакого реального преимущества при перемещении этого кода в других classах: концепция делегирования полностью выполняется с помощью основной логики данных, обрабатываемой делегатом приложения, поскольку основная модель данных на самом деле является фундаментальной частью вашего приложения;

2) Во всем примере кода, который я видел, включая образцы Apple, материал основных данных обрабатывается делегатом App;

3) Даже в книгах Core Data распространенной практикой является то, что делегат приложения обрабатывает основной код, связанный с данными;

4) Лично я не считаю, что читаемость или что-то еще на самом деле улучшается за счет наличия специальных classов для основных данных, но это вопрос личного вкуса, и я не буду спорить о том, какой подход является лучшим. Для меня важна простота при сохранении функциональности.

Вопрос, который я задал себе, в вашем случае, – это «кто делает« базовый стек данных »« принадлежащим »? Сами данные действительно являются областью приложения, не так ли? (CF Core Data на Mac, где у вас может быть приложение, способное работать с несколькими документами одновременно, поэтому стек Core Data принадлежит каждому документу).

В любом приложении Cocoa / Cocoa Touch приложение-делегат обычно является предпочтительным средством настройки поведения приложения, поэтому это естественное место для стека Core Data.

Теперь проблема, которую я подозреваю, у вас есть, заключается в том, что он чувствует себя не так постоянно, чтобы писать такие вещи, как:

 NSManagedObjectContext *context = [(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext]; 

То, что я обычно делаю в этих случаях, это функции записи (а не методы):

 NSManagedObjectContext *UIAppManagedObjectContext() { return [*(MyAppDelegate *)[[UIApplication sharedApplication] delegate] managedObjectContext]; } 

Я пишу аналогичную функцию для NSPersistentStoreCoordinator и NSManagedObjectModel . Я помещал все это в файлы .h / .m в приложении App Delegate, так как это объекты уровня приложения.

Я просто перечислил это в новом ответе. (Я отменил свой предыдущий class FJSCoreDataStack в пользу этого)

Моим новым способом справиться с этим было использование категории в NSManagedObjectContext. Ive добавил следующие методы classа:

 + (NSManagedObjectContext *)defaultManagedObjectContext; + (NSManagedObjectContext *)scratchpadManagedObjectContext; + (NSManagedObjectModel *)managedObjectModel; + (NSPersistentStoreCoordinator *)persistentStoreCoordinator; + (NSString *)applicationDocumentsDirectory; 

Это держит все из моего делегата приложения и дает доступ к singleton, если я захочу его использовать. Тем не менее, я все еще использую инъекцию зависимостей из App Delegate (как сказал mmalc, он вводит негибкость в мой код). Я просто переместил весь код «Core Data Stack» в категорию NSManagedObjectCOntext.

Мне нравится передавать ссылку, особенно потому, что у меня есть хороший «контекст контекста». Это позволяет гибким образом контролировать мои controllerы View, поскольку я не передал их «defaultManagedObjectContext».

Также имеет отношение к разговору в мире iPhone (и может иметь отношение к вашей архитектуре): NSFetchedResultsController и построение NSFetchRequests

Я за то, что делегат приложения знает, где начинается модель, и имея модель, где находится Контекст управляемого объекта. «Основная информация» модели представляется мне как модель реализации модели, classы controllerа (например, делегат приложения) должны просто спросить «дать мне эту информацию о модели», и модель должна знать, как ответить этот вопрос. Поэтому наличие объекта Core Data, доступного через объект controllerа, похоже на простую абстракцию.

  • Использование Apple FFT и Accelerate Framework
  • Как остановить прокрутку UITextView при входе в нее
  • Пользовательский интерфейс UINavigationBar
  • Встроенное видео HTML5 на iPhone против iPad / браузера
  • applicationWillTerminate, когда он вызывается, а когда нет
  • Как загрузить фотографию на сервер с помощью iPhone?
  • IPhone записывает видео, которые вращаются в системах Windows
  • Могу ли я загрузить UIImage из URL-адреса?
  • UIPopoverPresentationController на iOS 8 iPhone
  • Мое приложение «содержит шифрование»?
  • Заблокировать iPhone / iPod / iPad, чтобы он мог запускать только одно приложение
  • Давайте будем гением компьютера.