Базовые основы данных
Эта статья описывает базовую Базовую архитектуру Данных и способ, которым Вы используете платформу.
Базовая базовая архитектура данных
В большинстве приложений Вам нужны средние значения для открытия файла, содержащего архив объектов и ссылку по крайней мере на один корневой объект. Если Вы хотите поддерживать отмену — для отслеживания изменений в объектах, также необходимо быть в состоянии заархивировать все объекты к файлу и —. Например, в приложении для управления сотрудником, Вам нужны средние значения для открытия файла, содержащего архив сотрудника и объектов отдела и ссылки по крайней мере на один корневой объект — например, массив всех сотрудников — как проиллюстрировано на рисунке 1. Также необходимо быть в состоянии заархивировать к файлу всех сотрудников и все отделы.
Вы ответственны за запись кода, управляющего этими задачами любой полностью или частично. Например, на рабочем столе OS X, архитектура документа Какао обеспечивает структуру приложения и функциональность, помогающую сократить нагрузку, но Вы все еще имеете к методам записи поддерживать архивацию и разархивирование данных, отслеживать объекты модели и взаимодействовать с менеджером по отмене для поддержки отмены.
Используя Базовую платформу Данных, большая часть этой функциональности предоставлена для Вас автоматически, прежде всего через объект, известный как контекст управляемого объекта (или просто «контекст»). Контекст управляемого объекта служит Вашим шлюзом к базовому набору объектов платформы — коллективно известный как штабель персистентности — что промежуточный между объектами в Вашем приложении и внешних хранилищах данных. У основания штабеля хранилища постоянного объекта, как проиллюстрировано на рисунке 2.
Базовые Данные не ограничиваются основанными на документе приложениями — действительно возможно создать Базовую Основанную на данных утилиту без пользовательского интерфейса вообще (см. Базовое Учебное руководство по Утилите Данных). Те же принципы применяются в других приложениях.
Управляемые объекты и контексты
Можно думать о контексте управляемого объекта как об интеллектуальной временной памяти. При выборке объектов от персистентного хранилища Вы приносите временные копии на временную память, где они формируют граф объектов (или набор графов объектов). Можно тогда изменить те объекты, однако, Вам нравится. Если Вы фактически не сохраняете те изменения, однако, персистентное хранилище остается неизменным.
Объекты модели, набрасывающиеся в Базовой платформе Данных, известны как управляемые объекты. Все управляемые объекты должны быть зарегистрированы в контексте управляемого объекта. Вы добавляете объекты к графику и удаляете объекты из графика с помощью контекста. Контекст отслеживает изменения, которые Вы вносите, и к атрибутам отдельных объектов и к отношениям между объектами. Путем отслеживания изменений контекст в состоянии обеспечить отмену и поддержку восстановления Вас. Это также гарантирует, что при изменении отношений между объектами сохраняется целостность графа объектов.
Если Вы принимаете решение сохранить изменения, Вы сделали, контекст гарантирует, что Ваши объекты находятся в допустимом состоянии. Если они, то изменения записаны в персистентное хранилище (или хранилища) и новые записи, добавленные для объектов, которые Вы создали и записи, удаленные для объектов, которые Вы удалили.
У Вас может быть больше чем один контекст управляемого объекта в Вашем приложении. Для каждого объекта в персистентном хранилище может быть самое большее один соответствующий управляемый объект, связанный с данным контекстом (для большего количества подробных данных, посмотрите Faulting и Uniquing). Для рассмотрения этого от другой точки зрения данный объект в персистентном хранилище может быть отредактирован больше чем в одном контексте одновременно. Каждый контекст, однако, имеет свой собственный управляемый объект, соответствующий исходному объекту, и каждый управляемый объект может быть отредактирован независимо. Это может привести к несоответствиям во время сохранения — Базовые Данные обеспечивают много способов иметь дело с этим (см., например, Используя Управляемые объекты).
Запросы выборки
Для получения данных с помощью контекста управляемого объекта Вы создаете запрос выборки. Запрос выборки является объектом, указывающим, какие данные Вы хотите, например, “все Сотрудники”, или “все Сотрудники в Маркетинговом отделе, упорядоченном зарплатой, самой высокой самому низкому”. Запрос выборки имеет три части. Минимально это должно указать имя объекта (косвенно, можно только выбрать один тип объекта за один раз). Это может также содержать объект предиката, указывающий условия, которые объекты должны соответствовать и массив объектов дескриптора вида, указывающий порядок, в котором объекты должны появиться, как проиллюстрировано на рисунке 3.
Вы отправляете запрос выборки к контексту управляемого объекта, возвращающему объекты, соответствующие Ваш запрос (возможно ни один) от источников данных, связанных с его персистентными хранилищами. Так как все управляемые объекты должны быть зарегистрированы в контексте управляемого объекта, объекты, возвращенные из выборки, автоматически регистрируются в контексте, который Вы использовали для выборки. Вспомните, хотя это для каждого объекта в персистентном хранилище может быть самое большее одним соответствующим управляемым объектом, связанным с данным контекстом (см. Faulting и Uniquing). Если контекст уже содержит управляемый объект для объекта, возвращенного из выборки, то существующий управляемый объект возвращается в результатах выборки.
Платформа пытается быть максимально эффективной. Базовые Данные являются управляемым требованием, таким образом, Вы не создаете больше объектов, чем Вам фактически нужно. График не должен представлять все объекты в персистентном хранилище. Просто указание персистентного хранилища не приносит объектов данных в контекст управляемого объекта. При выборке подмножества объектов от персистентного хранилища Вы только получаете объекты, которые Вы попросили. Если Вы следуете за отношением к объекту, не выбранному, это выбирается автоматически для Вас. Если Вы прекратите использовать объект, то по умолчанию он будет освобожден. (Это - конечно, не то же как удаление его от графика.)
Персистентный координатор хранилища
Как отмечено ранее, набор платформы возражает, что промежуточный между объектами в Вашем приложении и внешних хранилищах данных именуется коллективно как штабель персистентности. Наверху штабеля контексты управляемого объекта, у основания штабеля хранилища постоянного объекта. Между контекстами управляемого объекта и хранилищами постоянного объекта там персистентный координатор хранилища.
В действительности персистентный координатор хранилища определяет штабель. Координатор разработан для представления фасада контекстам управляемого объекта так, чтобы группа персистентных хранилищ появилась как единственное совокупное хранилище. Контекст управляемого объекта может тогда создать граф объектов на основе объединения всех хранилищ данных покрытия координатора. Координатор может только быть связан с одной моделью управляемого объекта. Если Вы хотите поместить различные объекты в различные хранилища, необходимо разделить объекты модели путем определения конфигураций в моделях управляемого объекта (см. Конфигурации).
Рисунок 4 показывает пример, где сотрудники и отделы сохранены в одном файле, и клиентах и компаниях в другом. Когда Вы выбираете объекты, они автоматически получены от надлежащего файла, и когда Вы сохраняете, они архивируются к надлежащему файлу.
Персистентные хранилища
Данное хранилище постоянного объекта связано с единственным файлом или другим внешним хранилищем данных и в конечном счете ответственно за отображение между данными в том хранилище и соответствующими объектами в контексте управляемого объекта. Обычно, единственное взаимодействие, которое Вы имеете с хранилищем постоянного объекта, состоит в том при указании расположения нового внешнего хранилища данных, которое будет связано с приложением (например, когда пользователь открывает или сохраняет документ). Большинство других взаимодействий с Базовой платформой Данных через контекст управляемого объекта.
Ваш код приложения — и в частности прикладная логика, связанная с управляемыми объектами — не должна делать предположения о персистентном хранилище, в котором могут находиться данные. Базовые Данные предоставляют собственную поддержку для нескольких форматов файлов. Можно выбрать, чтобы использовать в зависимости от потребностей приложения. Если на некотором этапе Вы решаете выбрать различный формат файла, Ваша архитектура приложения остается неизменной. Кроме того, если Ваше приложение будет соответственно абстрагировано, то Вы будете в состоянии использовать в своих интересах более поздние улучшения к платформе без любого дополнительного усилия. Например —, даже если начальное внедрение в состоянии выбрать записи только от локальной файловой системы — если приложение не делает предположений о том, где это получает свои данные от, тогда если в некоторой более поздней поддержке этапа добавляется для нового типа удаленного персистентного хранилища, она должна быть в состоянии использовать этот новый тип без версий кода.
Персистентные документы
Можно создать и сконфигурировать штабель персистентности программно. Во многих случаях, однако, Вы просто хотите создать основанное на документе приложение, которое в состоянии считать и записать файлы. NSPersistentDocument класс является подклассом NSDocument это разработано, чтобы позволить Вам легко использовать в своих интересах Базовую платформу Данных. По умолчанию, NSPersistentDocument экземпляр создает свой собственный готовый к использованию штабель персистентности, включая контекст управляемого объекта и единственное хранилище постоянного объекта. Существует в этом случае непосредственное отображение между документом и внешним хранилищем данных.
NSPersistentDocument класс обеспечивает методы для доступа к контексту управляемого объекта документа и обеспечивает реализации стандарта NSDocument методы, чтобы читать и записать файлы, использующие Базовую платформу Данных. По умолчанию Вы не должны писать дополнительный код для обработки объектной персистентности. Функциональность отмены персистентного документа интегрируется с контекстом управляемого объекта.
Управляемые объекты и модель управляемого объекта
В порядке и чтобы управлять графом объектов и поддерживать объектную персистентность, Базовым Данным нужно богатое описание объектов, на которые это воздействует. Модель управляемого объекта является схемой, предоставляющей описание управляемых объектов или объекты, используемые Вашим приложением, как проиллюстрировано на рисунке 5. Вы обычно создаете модель управляемого объекта графически с помощью Средства проектирования Модели данных XCode. (При необходимости чтобы можно было создать модель программно во время выполнения.)
Модель составлена из набора объектов описания объекта, что каждый обеспечивает метаданные об объекте, включая имя объекта, имя класса, представляющего его в Вашем приложении (это не должно совпадать с его именем), и его атрибуты и отношения. Атрибуты и отношения поочередно представлены атрибутом и объектами описания отношения, как проиллюстрировано на рисунке 6.
Управляемые объекты должны быть экземплярами также NSManagedObject или подкласса NSManagedObject. NSManagedObject в состоянии представлять любой объект. Это использует частное внутреннее хранилище для поддержания его свойств и реализует все основное поведение, требуемое управляемого объекта. Управляемый объект имеет ссылку на описание объекта для объекта, которого это - экземпляр. Это обращается к описанию объекта для обнаружения метаданных о себе, включая имя объекта, который это представляет и информация о ее атрибутах и отношениях. Можно также создать подклассы NSManagedObject реализовать дополнительное поведение.