Модели управляемого объекта
Большая часть функциональности Базовых Данных зависит от схемы, которую Вы создаете для описания объектов приложения, их свойств и отношений между ними. Схема представлена моделью управляемого объекта — экземпляр NSManagedObjectModel. В целом, чем более богатый модель, тем лучшие Базовые Данные в состоянии поддерживать Ваше приложение. Эта статья описывает функции модели управляемого объекта, как Вы создаете один, и как Вы используете ее в своем приложении.
Функции модели управляемого объекта
Модель управляемого объекта является экземпляром NSManagedObjectModel класс. Это описывает схему — набор объектов — что Вы используете в своем приложении. (Если Вы не понимаете термин «объект» — или связанные условия, «свойство», «атрибут» и «отношение» — необходимо сначала считать Базовые Основы Данных и Объектное моделирование.)
Объекты
Модель содержит NSEntityDescription объекты, представляющие объекты модели. Две важных функции объекта являются его именем, и имя класса раньше представляло объект во время выполнения. Необходимо стараться сохранить ясными различия между объектом, класс используемый для представления объекта и управляемых объектов, которые являются экземплярами того объекта.
NSEntityDescription объект может иметь NSAttributeDescription и NSRelationshipDescription объекты, представляющие свойства объекта в схеме. Объект, возможно, также выбрал свойства, представленные экземплярами NSFetchedPropertyDescription, и модель может иметь шаблоны запроса выборки, представленные экземплярами NSFetchRequest.
В модели объекты могут быть расположены в иерархии наследования, и объекты могут быть указаны как краткий обзор.
Наследование объекта
Наследование объекта работает похожим способом к наследованию классов и полезно по тем же причинам. Если у Вас есть много объектов, которые подобны, Вы можете фактор общая собственность в суперобъект. Вместо того, чтобы указывать те же свойства в нескольких объектах, можно определить их в одном, и подобъекты наследовали их. Например, Вы могли бы определить объект Лица с помощью атрибутов firstName и lastName, и Сотрудника подобъектов и Клиента, наследовавших те атрибуты.
Во многих случаях Вы также реализуете пользовательский класс для соответствия объекту, от которого также наследовались классы, представляющие подобъекты. Вместо того, чтобы реализовывать бизнес-логику, характерную для всех объектов несколько раз, Вы реализуете их в одном месте, и они наследованы подклассами.
При создании модели с помощью инструмента моделирования данных в XCode Вы указываете родителя объекта путем выбора имени объекта от Родительского всплывающего меню в Информационной панели объекта, как показано на рисунке 1.
Если Вы хотите создать иерархию наследования объекта в коде, необходимо создать его сверху вниз. Вы не можете установить суперобъект объекта непосредственно, можно только установить подобъекты объекта (использующий метод setSubentities:). Для установки суперобъекта для данного объекта необходимо поэтому установить массив подобъектов для того супер объекта и включать текущий объект в тот массив.
Абстрактные объекты
Можно указать, что объект абстрактен — т.е. что Вы не создадите экземпляров того объекта. Вы обычно делаете краткий обзор объекта, если у Вас есть много объектов, что все представляют специализации (наследуйтесь от), общий объект, который нельзя самостоятельно инстанцировать. Например, в приложении получения у Вас мог бы быть Графический объект, определяющий атрибуты для координат x и y, цвета и рисующих границ. Вы никогда, тем не менее, инстанцируете Диаграммы. Конкретные подобъекты Графических могли бы быть Кругом, TextArea и Строкой.
Свойства
Свойства объекта являются его атрибутами и отношениями, включая его выбранные свойства (если это имеет кого-либо). Среди других функций каждое свойство имеет имя и тип. Атрибуты могут также иметь значение по умолчанию. Имя свойства не может совпасть ни с каким именем метода без параметров NSObject или NSManagedObject— например, Вы не можете дать свойству имя «описание» (см. NSPropertyDescription).
Переходные свойства являются свойствами, которые Вы определяете как часть модели, но которые не сохраняются к персистентному хранилищу как часть данных экземпляра объекта. Базовые Данные действительно отслеживают изменения, которые Вы вносите в переходные свойства, таким образом, они зарегистрированы для операций отмены.
Атрибуты
Базовые Данные исходно поддерживают множество типов атрибута, таких как строка, дата и целое число (представленный как экземпляры NSString, NSDate, и NSNumber соответственно). Если Вы хотите использовать тип атрибута, исходно не поддерживающийся, можно использовать один из методов, описанных в Нестандартных Персистентных Атрибутах.
Можно указать, что атрибут является дополнительным — т.е. он не требуется, чтобы иметь значение. В целом, однако, Вы отговорены делать так — специально для числовых значений (обычно, можно получить лучшие результаты с помощью обязательного атрибута со значением по умолчанию — в модели — 0). Причина этого состоит в том, что SQL имеет специальное поведение сравнения для NULL это непохоже на Objective C nil. NULL в базе данных не то же как 0, и поиски 0 не будет соответствовать столбцы NULL.
false == (NULL == 0) |
false == (NULL != 0) |
Кроме того, NULL в базе данных не эквивалентно пустой строке или пустому блобу данных, также:
false == (NULL == @"") |
false == (NULL != @"") |
Это не имеет никакого влияния на отношения.
Отношения
Базовая Информационная поддержка к - один и к - много отношений и выбранных свойств. Выбранные свойства представляют слабые, односторонние отношения. В домене сотрудников и отделов выбранное свойство отдела могло бы быть «недавней высокой разрешающей способностью» (у сотрудников нет инверсии к недавнему с высокой разрешающей способностью отношению).
Можно указать возможности и кардинальность отношения и удалять правило. Необходимо обычно моделировать отношение в обоих направлениях. Many-many отношение - то, в котором отношение и его инверсия оба к - многие. Отношения описаны более подробно в Отношениях и Выбранных Свойствах.
Шаблоны запроса выборки
Вы используете NSFetchRequest класс для описания выборки запрашивает получить объекты от персистентного хранилища. Часто имеет место, что Вы хотите выполнить тот же запрос в многократных случаях или выполнить запросы, следующие за данным образцом, но содержащие переменные элементы (обычно предоставленный пользователем). Например, Вы могли бы хотеть быть в состоянии получить все публикации, записанные определенным автором, возможно после даты, указанной пользователем во время выполнения.
Можно предопределить запросы выборки и сохранить их в модели управляемого объекта как названных шаблонами. Это позволяет Вам предопределять запросы, которые можно получить по мере необходимости от модели. Как правило, Вы определяете шаблоны запроса выборки с помощью инструмента моделирования данных XCode (см. Инструменты XCode для Базовых Данных). Шаблон может включать переменные, как показано на рисунке 2.
Для больше об использовании шаблонов запроса выборки, посмотрите Доступ и Используя Модель Управляемого объекта во Время выполнения.
Пользовательские информационные словари
Многие элементы в модели управляемого объекта — объекты, атрибуты, и отношения — имеют связанный пользовательский информационный словарь. Можно поместить любую информацию, которую Вы хотите в пользовательский информационный словарь как пары ключ/значение. Общая информация для помещения в пользовательский информационный словарь включает подробные данные версии для объекта и оценивает используемый предикатом для выбранного свойства.
Конфигурации
Конфигурация имеет имя и связанный набор объектов. Наборы могут наложиться — т.е. данный объект может появиться больше чем в одной конфигурации. Вы устанавливаете конфигурации программно с помощью setEntities:forConfiguration: или использование инструмента моделирования данных XCode (см. Инструменты XCode для Базовых Данных), и получает объекты для данного использования имени конфигурации entitiesForConfiguration:.
Если Вы хотите сохранить различные объекты в различных хранилищах, Вы обычно используете конфигурации. У персистентного координатора хранилища может только быть одна модель управляемого объекта, таким образом, по умолчанию каждое хранилище, связанное с данным координатором, должно содержать те же объекты. Для работы вокруг этого ограничения можно создать модель, содержащую объединение всех объектов, которые Вы хотите использовать. Вы тогда создаете конфигурации в модели для каждого из подмножеств объектов, которые Вы хотите использовать. Можно тогда использовать эту модель при создании координатора. Когда Вы добавляете хранилища, Вы указываете различные атрибуты хранилища конфигурацией. Когда Вы создаете свои конфигурации, тем не менее, помнят, что Вы не можете создать отношения перекрестного хранилища.