ios/xcode: лучшее место для свойств и методов Core Data

Question

Я следил за различными учебными пособиями по основным данным, и все они, похоже, рекомендуют разные места, чтобы поместить основной код данных, то есть свойства и методы для nsmanagedobject, nsmanagedobjectcotext и nspersistent store Coordinator ,

В проекте примера Xcode они помещают его в делегат приложения.

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

Еще один вариант, который у меня есть видимо, это поставить его в контроллер просмотра. Но это не похоже на хороший пример MVC.

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

спасибо.

Answer 1

Положить логику в класс Model, например методы для NSManagedObjectContext и NSPsistentStoreCкоординатора. Этот класс может наследовать от NSObject.

Создайте классы (если необходимо) для объектов NSManagedObjects. Моя рекомендация - сохранить столько логики вне ваших классов сущностей. Заманчиво добавлять логику в класс сущности, чтобы реагировать на значения атрибутов (или изменения). Но при оценке этого подхода учитывайте, что ваш NSManagedObject довольно короткий. Не пропускайте его внутри своего приложения. NSManagedObject может быть превращен в неисправность, и ваша логика больше не будет доступна.

Рассмотрите возможность перемещения логики в отдельный класс, который не наследуется от NSManagedObject. Это может быть ваш класс Model. Выполните требуемую логику внутри этого класса Model. Этот класс не будет винить вас, и у вас будет больше свобод с контекстами.

Затем: Не позволяйте Xcode воссоздавать файлы классов. После внесения изменений в обновление модели вручную файл класса NSManagedObject. Обновление типа файла класса должно выполняться только при изменении типа или имени атрибута.

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

Answer 2

Похоже, вы смешиваете пару разных вещей.

Шаблоны проектов Xcode помещают код для обработки NSPersistentStoreCoordinator и NSManagedObjectContext в делегат приложения. Это не страшно, но не очень хорошо, и многие другие примеры рекомендуют размещать его где-то в другом месте - например, какой-то класс управления основными данными.

Этот код не обрабатывает свойства или собственные методы на NSManagedObject экземплярах. Обычно они входят в подклассы NSManagedObject. Если вы используете Xcode для создания этих подклассов, вы правы, Xcode потеряет существующий код, если вы повторите этот процесс. Это удобно, но хрупко. Лучше использовать mogenerator, инструмент с открытым исходным кодом для генерации подклассов. Он создает два подкласса для каждого объекта. Вы помещаете свой собственный код в один и оставляете другого в покое. Если вы когда-либо повторно создавали файлы, то с вашим пользовательским кодом не будет перезаписываться.

Answer 3

Использование одного класса Model для всей логики - страшная идея, так как она быстро может стать God Object.

Вы можете добавить дополнительные методы в категории на подклассы NSManagedObject, чтобы они не перезаписывались после повторного генерации классов. Это будет работать для простых задач, таких как проверка данных (для этой цели есть даже встроенные методы: NSManagedObject) или простая фильтрация отношений «многие» (например, получение событий с прошлой недели в объекте Calendar). В конце концов, NSManagedObjects являются объектами, и объекты могут не только хранить данные, но и делать что-то. Я успешно использовал этот подход для приложения, имеющего ~ 50 объектов.

Для более сложных задач вы можете создавать простые подклассы NSObject, которые работают с управляемыми объектами. Например, в моем приложении я использовал класс MessageSynchronizer, который имел дело с объектами сущностей Message, отвечающими за синхронизацию сообщений с веб-службой (он не попадал в сеть, просто обрабатывая возможные конфликты между локальными и удаленными данными). Для задач, связанных с отображением данных (например, даты форматирования), вы можете использовать Model-View-ViewModel pattern и делать их в ViewModels. Просто помните о важных принципах ООП, таких как Single Responsibility Principle.