Каковы, если таковые имеются, негативные последствия создания слоя модели на NSManagedObject?

Question

Я работаю с iOS уже около двух лет, и в основном из-за простых слоев данных (нет необходимости в идентификаторах, объединениях, сложных запросах и т. Д.), Я всегда вручную управлял сохранением, расширяя NSObject, в NSCoder и сохранение моих данных в виде простых файлов.

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

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

Например, такие вещи как @dynamic getter / setters мне не понятны и т. Д.

Итак:

1) Существуют ли какие-либо функции NSManagedObject, которые не позволили бы мне обрабатывать экземпляры пользовательских классов так же, как и в NSObject?

2) Есть ли у NSManagedObject необычное поведение при обработке объектов БЕЗ наличия ManagedObjectContext?

3) Могу ли я заменить объявление свойства @dynamic своим собственным геттером / установщиком без особых проблем? Я использую множество пользовательских сеттеров для реализации бизнес-логики.

и так далее, и так далее.

Спасибо

Answer 1

Осторожно!

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

1) Существуют ли какие-либо функции NSManagedObject, которые не позволили бы мне обрабатывать экземпляры пользовательских классов так же, как и в NSObject?

Неисправности и жизненный цикл управляемых объектов немного сложны для понимания. Ваши объекты могут быть «повреждены» почти в любое время (в любом случае, на каждой итерации цикла событий), что приводит к потере непостоянного состояния. Когда они становятся «неповрежденными», они не имеют доступа ни к чему вне контекста управляемого объекта, чтобы восстановить свое состояние. Управляемым объектам очень трудно получить доступ к чему-либо вне контекста управляемого объекта.

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

Таким образом, в основном свойства управляемых объектов должны быть постоянными или связанными с постоянными свойствами. Посмотрите на объекты, которые вы планируете сделать управляемыми. Являются ли все их переменные экземпляра выполнимыми и желательными для хранения в постоянном хранилище? Если не все будет не так просто. Вы, вероятно, установили переменные вашего экземпляра в вашем init. Нет инициализации, которая вызывается каждый раз, когда ваша программа запускается для управляемых объектов. Есть awakeFromInsert и awakeFromFetch, но они не работают точно так же, как init. Ваш код вызывает init и может передавать аргументы. Фреймворк вызывает awake и не получает параметров.

Потоки - это еще одна проблема для рассмотрения. Контекст управляемого объекта и, следовательно, управляемые объекты в нем рекомендуется использовать только одному потоку. Если у вас есть несколько потоков, и им нужен доступ к вашей модели, вам необходимо создать дублированные контексты управляемых объектов, содержащие дубликаты ваших управляемых объектов. Базовые данные разработаны для того, чтобы справляться с этим без чрезмерной нагрузки на память, дисковый ввод-вывод и процессор, но они не легки с точки зрения кодирования.

2) Есть ли у NSManagedObject необычное поведение при обработке объектов БЕЗ наличия ManagedObjectContext?

Вы не можете иметь управляемый объект без контекста управляемого объекта.

Обычно это не проблема. Управляемые объекты содержат указатель на их контекст управляемого объекта. Это может быть немного ограничивающим, хотя. Если что-то за пределами вашей модели требует создания объекта модели в качестве входных данных для вашей модели, для этого ему необходим доступ к контексту управляемого объекта. Надеюсь, что это будет через какой-то уровень абстракции, поэтому ему не нужно знать, что он имеет дело с Core Data, но вы не можете просто дать ему класс и получить его alloc / init. Также необходимо проделать небольшую работу по перемещению управляемых объектов между различными контекстами управляемых объектов.

3) Могу ли я заменить объявление свойства @dynamic своим собственным геттером / сеттером без особых проблем? Я использую множество пользовательских сеттеров для реализации бизнес-логики.

Да. Это немного сложно, но выполнимо. Вы пишете свои собственные средства доступа. В дополнение к вашей бизнес-логике они должны вызывать методы наблюдения значения ключа, такие как willChangeValueForKey:. Затем вы получаете доступ к данным, используя примитивные методы доступа.

Answer 2

1) Существуют ли какие-либо функции NSManagedObject, которые не позволили бы мне обрабатывать экземпляры пользовательских классов так же, как и в NSObject?

Нет.Вы можете расширить подкласс NSManagedObject так же, как подкласс NSObject.

2) Есть ли у NSManagedObject необычное поведение при обработке объектов БЕЗ наличия ManagedObjectContext?

Директива @dynamic создаст методы доступа, оптимизированные для сохранения в персистентноммагазин управляется контекстом.Значения будут по-прежнему доступны, как и любой другой объект, но вы будете создавать много накладных расходов.

3) Могу ли я заменить объявление свойства @dynamic своим собственным средством получения / установки без особых проблем?Я использую множество пользовательских сеттеров для реализации бизнес-логики.

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

Отсутствует одна существенная путаница новичка в отношении управляемого объекта: универсальный NSManagedObject может представлять любую сущность в модели данных без создания подклассов.NSManagedObject имеет «ассоциативное хранилище», что означает, что к нему прикреплен открытый словарь, в котором сохраняются любые пары ключ-значение.Когда вы вставляете универсальный NSManagedObject в контекст, ключи «словаря» ассоциативного хранилища устанавливаются на имена свойств данной сущности.

Таким образом, вы фактически никогда не будете вынуждены создавать подкласс NSManagedObject.Это в значительной степени вопрос удобства.

Вот почему вы иногда видите код, который использует универсальный NSManagedObject и setValue:forKey, а иногда вы видите пользовательские подклассы, которые используют anObject.propertyName.

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

Answer 3

1) Существуют ли какие-либо функции NSManagedObject, которые не позволили бы мне обрабатывать экземпляры пользовательских классов так же, как я бы делал с NSObject?

Создание и удаление их отличается, но не сложно,В противном случае, нет

2) Есть ли у NSManagedObject необычное поведение при обработке объектов БЕЗ наличия ManagedObjectContext?

Я не уверен, что вы имеете в виду, выВы можете передать управляемый объект другому классу и использовать его довольно счастливо, когда другой класс не знает о контексте, но вы должны иметь контекст где-то.

3) Могу ли я заменитьобъявление свойства @dynamic с моим собственным пользовательским getter / setter без особых проблем?Я использую множество пользовательских сеттеров для реализации бизнес-логики.

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

Основные данные - это, прежде всего, структура персистентности, а не структура запросов - япредставьте себе, как только вы это сделаете, вы удивитесь, почему вы тратите время на все эти реализации NSCoding ...