Хороший дизайн с использованием CoreData?

Question

Для использования CoreData многие разработчики наследуют объекты модели от NSManagedObject.

Но что, если бы я хотел сохранить свои объекты модели независимыми от используемого механизма хранения (возможно, я буду использовать их повторно в проекте, где мне вообще не требуется постоянство)?

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

Какой лучший подход?

Answer 1

В настоящее время нет способа создания сущностей, которые могут сохраняться Core Data, а также использоваться полностью отключенными от Core Data.Все, что наследуется от NSManagedObject, несет с собой некоторый багаж, не в последнюю очередь то, что вы не можете сериализовать его без какого-либо специального кода для каждого объекта.

Вы можете создать несколько протоколов, которые представляют каждую из ваших сущностей, которыеваши управляемые объекты Core Data соответствуют, как и ваши автономные объекты.Вы можете использовать категории на объектах NSO, которые соответствуют только вашему протоколу сущностей, для реализации поведения, разделяемого Базовыми данными и автономными сущностями.Делая категорию применимой только к классам, которые соответствуют вашему протоколу сущностей, вы предотвращаете применение категории к каждому объекту NSO (очень плохо).Вместо этого он применяется только к реализуемым вами классам, которые соответствуют этой категории.Я обнаружил, что это единственный способ поделиться кодом между сущностями базовых данных и автономными сущностями.

Чтобы предотвратить потерю любых изменений, вносимых в сущности базовых данных при каждом изменении модели, я использую mogenerator для восстановления сущностей вместо XCode.Это позволяет мне отделить специфичные для Core Data вещи от любых настроек, которые мне нужны для сущностей (например, применение протокола для сущности).Если вы используете XCode 3, в mogenerator есть плагин, который управляет интеграцией XCode.Если вы используете XCode 4, плагин не работает, но с помощью другого разработчика на DevForums я написал учебное пособие по настройке mogenerator.

Answer 2

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

Если вы все еще настаиваете на том, чтобы не наследовать ваши классы моделей от NSManagedObject, это может помочь объединить протоколы и категории, как описано в RyanR. Однако, на мой взгляд, у вас будут большие затраты на создание протоколов, категорий и дублирующих классов.

Answer 3

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

В случае базовых данных постоянство - это всего лишь вариант, он не требуется, поскольку базовые данные не являются в первую очередь постоянным API. Вместо этого это API-интерфейс управления графами объектов, предназначенный для предоставления полного уровня модели в приложении разработки Model-View-Controller. Это настоящая функция - управлять объектами на графике для точного моделирования / симуляции реальных объектов, условий или событий и отношений между ними.

Вы изменяете параметры сохранения на уровне координатора постоянного хранилища. У вас есть возможность использовать хранилище sqlite, двоичное хранилище, хранилище xml plist или хранилище в памяти, которое, как следует из названия, вообще не является «постоянным» хранилищем. У вас также есть возможность написать свой собственный магазин. Подробнее см. Темы программирования для магазина Atomic .

Вам действительно нужен контекст управляемого объекта, чтобы получить любое значение из Core Data. Вместо того, чтобы называть его «NSManagedObjectContext», они должны были назвать его «NSManagedObjectManager», потому что это было бы все, что автоматическое обслуживание графа объекта сделано. Если вы хотите дублировать эту функциональность, вам придется написать собственный класс менеджера.

На мой взгляд, лучший способ обеспечить страховку для той гибкости, которую вы стремитесь записать в методе сериализации в общий формат данных, такой как JSON. Затем, если вам нужно переключиться на другую опцию персистентности, вы можете просто преобразовать граф объекта Core Data в JSON и отправить куда угодно.

Однако я бы не стал беспокоиться, если вы уже не уверены наверняка, что такая функциональность понадобится. Это очень, очень редко. Лучше кодировать только для известных требований, а затем тратить время на новые требования только тогда, когда они действительно появляются.