Лучшие практики CoreData
Я использую CoreData в своем последнем приложении для iPhone. Я нахожу это сложным вначале, но я предполагаю, что это - лучший выбор, когда необходимо хранить объекты в приложении для iPhone (http://inessential.com/2010/02/26/on_switching_away_from_core_data).
Есть ли какие-либо лучшие практики при использовании CoreData в приложении для iPhone? Например, я не хочу, чтобы все мои контроллеры имели дело с этим NSManagedObjectContext, в котором Вы нуждаетесь, когда Вы хотите выполнить запросы. Вы определяете класс только для запросов CoreData?
2 ответа
Я обычно создаю специальный объект для управления своим стеком Core Data и связанными объектами и поведением. Это полезно, потому что есть много шаблонов с Core Data, поэтому я могу создать общий базовый класс менеджера, а затем использовать подкласс для каждого приложения. Обычно я называю это AppNameDataModel.
Я предпочитаю скрывать контекст управляемого объекта внутри объекта DataModel. Это заставляет другие объекты в приложении запрашивать у объекта DataModel доступ к стеку Core Data, что обеспечивает хорошую инкапсуляцию и безопасность.
Обычно я создаю методы в классе DataModel для возврата выборки для сущностей, например.
-(NSFetchRequest *) entityNameFetch;
... а затем использовать метод performFetch в DataModel. При использовании контроллер запрашивает выборку для объекта, настраивает выборку, а затем просит DataModel выполнить выборку и вернуть результаты. Вы можете создать сценарий для методов, которые возвращают выборку, и выполнение выборки также является шаблонным. Все это экономит много времени, особенно при создании прототипов.
Ссылка на сам экземпляр DataModel может быть передана от контроллера к контроллеру, но я думаю, что это допустимое использование шаблона singleton, поэтому я часто делаю DataModel одноэлементным и предоставляю категорию в UIViewController для свойства для доступа к нему. Это означает, что любой контроллер представления, который я добавляю в проект, автоматически получает доступ к DataModel.
Этот шаблон сохраняет все красиво инкапсулированным и модульным. Это упрощает добавление новых представлений или совместное использование модели данных между проектами. Первоначальная настройка требует небольшой работы, но когда у вас есть базовый класс, его дальнейшее использование значительно ускоряется.
Спасибо, Брэд, за указание на этот вопрос.
Как упоминалось в документации Apple [1], контекст должен передаваться каждому новому контроллеру представления, которому требуется CoreData.
На iPhone:
По соглашению часто можно получить контекст из контроллера представления. Впрочем, следовать этому образцу зависит только от вас. Когда вы реализуете контроллер представления, который интегрируется с Core Data, вы можете добавить свойство NSManagedObjectContext.
Контроллер представления обычно не должен извлекать контекст из глобального объекта, такого как делегат приложения. Это делает архитектуру приложения жесткой.Контроллер представления также не должен создавать контекст для собственного использования. Это может означать, что операции, выполняемые с использованием контекста контроллера, не регистрируются в других контекстах, поэтому разные контроллеры представления будут иметь разные точки зрения на данные.
Когда вы создаете контроллер представления, вы передаете ему контекст. Вы передаете существующий контекст или (в ситуации, когда вы хотите, чтобы новый контроллер управлял дискретным набором изменений) новый контекст, который вы для него создаете. Обычно ответственность за создание контекста для передачи первому отображаемому контроллеру представления лежит на делегате приложения.