Почему именно один подкласс NSManagedObject?

Ответ 1

Я до сих пор не понимаю, для чего подклассифицируется NSManagedObject - какую роль он играет?

Удобство для разработчика - с точки зрения CodeSense, более короткого синтаксиса и некоторых проверок времени компиляции, которые помогают нарушать орфографические ошибки.

так что я могу сделать с NSManagedObject? Каковы ограничения, должны следовать рекомендациям и какие не являются ограничениями?

Пользовательский интерфейс, встроенный в Xcode, сделает для вас подклассы NSManagedObject - вам действительно не нужно делать это вручную, но, в основном, они просто NSManagedObject с некоторыми свойствами, на которые наложены. Вместо использования @synthesize или такого, вы используете @dynamic, и Apple позаботится об остальном для вас - подключении этих свойств к геттерам/сеттерам, которые имитируют то, что вы обычно делаете с "голым" NSManagedObject.

Я пытаюсь сделать небольшую программу рисования ящиков для изучения Core Data, и я подумываю добавить методы "draw" к подклассу NSManagedObject, чтобы представление просто подсказывало им рисовать для себя - это Допустимость

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

Объекты модели не должны содержать код бизнес-логики/чертежа. Используйте модель просто как "состояние" вашего приложения. Сделайте что-то еще ответственное за рисунок. Плюс, хотя я не могу сказать это с абсолютной властью, я считаю, что есть некоторые накладные расходы, если вы имеете дело с обновлением/извлечением информации из NSManagedObject.

(В принципе, это похоже на работу с NSDictionary... sorta. Менее эффективно захватывать элементы из словаря, чем обращаться к ivar.)

Для приложения, которое делает такие вещи, как рисование, вы, вероятно, захотите избежать этих накладных расходов, создав структуру для своих вещей в памяти и, возможно, вторую аналогичную структуру для сохранения/сериализации (например, для CoreData).

Итак, мой вопрос в одном предложении был бы тем, что "реальная" разница между подклассом NSManagedObject и любым другим классом - что делает Основные данные делают с ним?

Я бы сказал - не подклассы NSManagedObject от руки вообще - используйте то, что дает Xcode. Если вы хотите больше (кроме, может быть, настраиваемого конструктора), вы, вероятно, будете лаять неправильное дерево.

EDIT:

Я думаю, что может быть некоторая путаница в том, что я имел в виду, когда я сказал: "Не подклассы NSManagedObject вручную"

Чтобы разработать и включить один из ответов:

Начните с дизайнера модели данных в Xcode, создайте свои модели и используйте следующую опцию меню:

Затем вы можете изменить сгенерированный класс, чтобы включить custom:

• Конструкторы
• Методы преобразования данных
• Проверка
• Форматирование
• Сортировка дескрипторов
• Фильтры

Если ваш прецедент не подходит в этом списке, вы действительно должны серьезно подумать о том, чтобы поместить его в другое место (как в вашем примере с методом "Draw" ).

Все перечисленные выше могут быть привязаны к подклассу NSManagedObject, который был создан для нас с помощью Xcode (мы не создали "вручную" ) - и все они вращаются вокруг работы с данными напрямую (форматы/конверсии/etc) и/или вокруг вытягивания данных из Core Data (фильтры/сортировка).

Они не добавляют iVars, они не выполняют каких-либо сложных операций за пределами области хранения и извлечения данных.