Основы Core Data в среде Cocoa, Mac OS, iOS

Cocoa

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

Вы несете ответственность за написание кода, который управляет этими задачами в целом или в части. Например, в Mac OS X, архитектура Cocoa документа содержит структуру приложения и функции, которые помогают уменьшить нагрузку, но вам все равно придется писать методы для поддержки архивирования и разархивирования данных, чтобы отслеживать модели объектов, и взаимодействовать с менеджером отмены (undo).

Рисунок 1. Документ управления с использованием стандартной архитектуры документа Cocoa

Core Data стандартная архитектура Cocoa Document

С использованием Core Data framework, большинство из этих функций обеспечивается автоматически, в первую очередь через объект, известный как управляемый объект контекста (или просто "контекст"). Управляемый объект контекста служит в качестве шлюза для основной коллекции объектов, известных под общим названием сохранение стека, некиим посредником между объектами приложения и внешним хранилищем данных. В нижней части стека постоянное хранилище объекта, как показано на рисунке 2.

Рисунок 2. Управление документооборотом с использованием Core Data.

Core Data пример

Основные данные не ограничивается документ-приложениями, на самом деле можно создать Core Data-утилиты без интерфейса пользователя вообще.

Управляемые объекты и контекст

Вы можете думать об управляемом объекте контекста как о интеллектуальном редакторе. Когда Вы выбираете объекты из постоянного хранилища, вы переносите временные копии на блокнот, где они образуют объект граф (или набор объектов графики). Вы можете изменять эти объекты, как вам нравится. Однако, постоянное хранилище, остается неизменным.

Модели объектов, которые связывают в рамках Core Data известны как управляемые объекты. Все управляемые объекты должны быть зарегистрированы в управляемом объекте контекста. Для добавления объектов к графу и удаления объектов из графа, используют контекст. Контекст отслеживает изменения, которые вы делаете, как отдельных атрибутов объектов, так и связей между объектами. Отслеживания изменения контекста в состоянии обеспечить поддержку отмены и повтора (undo, redo), а также гарантирует, что если вы изменили отношения между объектами, целостность графа объектов сохраняется.

Если вы хотите сохранить сделанные вами изменения, контекст гарантирует, что ваши объекты находятся в допустимом состоянии. Если это так, то изменения будут записаны в постоянное хранилище (или хранилища), добавит новые записи для объектов, созданных и удалит записи для объектов, которые удалены.

Вы можете иметь более одного управляемого объекта контекста в вашем приложении. Для каждого объекта в постоянном хранилище может быть не более одного соответствующего управляемого объекта, связанного с данным контекстом. Чтобы рассмотреть это с другой точки зрения, данный объект в постоянном хранилище может быть изменен более чем в одном контексте одновременно. Каждый контекст, однако, имеет свой управляемый объект, соответствующий исходному объекту, и каждый управляемый объект может быть отредактирован независимо друг от друга. Это может привести к противоречиям во время сохранения, Core Data предоставляет несколько способов справиться с этим.

Запрос выборки

Для получения данных с помощью управляемого объекта контекста, необходимо создать запрос выборки. Получить запрос объекта, который определяет, какие данные вы хотите, например, "все сотрудники", или "все сотрудники в отделе маркетинга по заказу зарплаты, от большего к меньшему". Получение запроса состоит из трех частей. Минимально он должен указывать на имя лица (по смыслу, вы можете получить только одно лицо за один раз). Он также может содержать объект предикат, который определяет условия, которым объекты должны соответствовать и массив объектов дескрипторов, который определяет порядок, в котором объекты должны появиться, как показано на рисунке 3.

Рисунок 3. Пример запроса выборки

Core Data пример запроса

Вы отправляете запрос на выборку управляемому объекту контекста, который возвращает объекты, которые соответствуют вашему запросу (возможно, нет) из источников данных, связанных с его постоянным хранилищем. Так как все управляемые объекты должны быть зарегистрированы в управляемом объекте контекста, объекты, возвращаемые из выборки будут автоматически зарегистрированы в контексте используемом для извлечения. Однако, необходимо помнить, что для каждого объекта в постоянном хранилище может быть не более одного соответствующего управляемогой объекта, связанного с данным контекстом. Если контекст уже содержит управляемый объект для объекта, возвращенного из выборки, то существующий управляемый объект возвращается в выборку результатов.

Framework старается быть как можно более эффективным. Core Data зависит от спроса, так что вы не создаете больше объектов, чем вам действительно нужно. Граф не должен представлять все объекты в постоянном хранилище. Просто указавая постоянному хранилищу не доставлять никаких данных объектов в управляемый контекст объекта. Когда Вы выбираете множество объектов из постоянного хранилища, вы получите только объекты, которые вы запросили. Если вы будете следовать по отношению к объекту, который не доставлен, он извлекается автоматически. Если вы прекратите использование объекта, по умолчанию он будет освобожден. (Это, конечно, не тоже самое, как удалить его из графа.)

Постоянный координатор хранилища

Как отмечалось ранее, коллекция объектов framework, является посредником между объектами приложения и внешними хранилищами данных, и именуется стеком сохранения. В верхней части стека управляемый объект контекста, в нижней части стека постоянное хранилище объекта. Между управляемым объектом контекста и постоянным хранилищем объекта есть постоянный координатор хранилища.

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

На рисунке 4 показан пример, в котором сотрудники и департаменты хранятся в одном файле, а клиенты и компании в другом. Когда Вы выбираете объекты, то они автоматически извлекаются из соответствующих файлов, и при сохранении, они архивируются в соответствующий файл.

Рисунок 4. Расширенный постоянный стек

Core Data стек пример

Постоянные хранилища

Заданный объект постоянного хранилища связан с одним файлом или другим внешним хранилищем данных и, в конечном счете ответственнен за соответствие между данными, которые хранятся и соответствующих объектах в управляемом контексте объекта. Как правило, только у вас есть взаимодействие с объектом постоянного хранилища, когда вы укажите расположение нового внешнего хранилища данных, связанного с приложением (например, когда пользователь открывает или сохраняет документ). Большинство других взаимодействий с Core Data framework, выполняются через управляемй объект контекста.

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

Важно хотя Core Data и поддерживает SQLite в качестве одного из постоянный типов хранилища, Core Data, не может управлять любой произвольной базой данных SQLite. Для того, чтобы использовать базу данных SQLite, Core Data должно создавать и управлять самой базой данных.

Постоянные документы

Вы можете создать и настроить сохранение стека программными средствами. Однако, во многих случаях, вы просто создаете документ-приложение, которое может читать и записывать файлы. NSPersistentDocument класс является подклассом NSDocument, которые разработаны, чтобы позволить вам легко воспользоваться Core Data framework. По умолчанию, например, NSPersistentDocument создает свой собственный готовый к использованию постоянный стек, включая управляемый объект контекста и одно постоянное хранилище объектов. В этом случае осуществляется однин в один соответствие между документами и внешним хранилищем данных.

Класс NSPersistentDocument предоставляет методы для доступа к управляемому объекту контекста документа и обеспечивает реализацию стандартных NSDocument методов для чтения и записи файлов, которые используются Core Data framework. По умолчанию вам не придется писать дополнительный код для обработки сохранения объектов. В постоянный документ функциональность отмены (undo) интегрирована с управляемым контекстом объекта.

Управляемые объекты и управляемая объектная модель

В целях управления графом объектов и для поддержки постоянного хранения объектов, Core Data нужны широкие описания объектов, с которыми он работает. Управляемый объект модели это схема, которая обеспечивает описание управляемых объектов или объектов, используемых приложением, как показано на рисунке 5. Как правило, создание управляемой объектной модели выполняется графически с использованием данных Xcode в инструменте дизайнера модели. (Если вы захотите, то можете построить модель программно во время выполнения.)

Рисунок 5 управляемый объект модели с двумя субъектами

Core Data Управляемая модель объектов

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

Рисунок 6 сущности описаннные с двумя атрибутами и отношениями

Core Data сущности

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

 
 
homeЗаметили ошибкукарта сайта 
   Made on a Mac