Core Data — это объектный граф и структура сохранения , предоставляемая Apple в операционных системах macOS и iOS . Она была представлена в Mac OS X 10.4 Tiger и iOS с iPhone SDK 3.0. [1] Она позволяет сериализовать данные, организованные реляционной моделью сущности-атрибута, в хранилища XML , двоичные или SQLite . Данными можно манипулировать с помощью объектов более высокого уровня, представляющих сущности и их отношения. Core Data управляет сериализованной версией, обеспечивая жизненный цикл объекта и управление графом объекта , включая сохранение . Core Data напрямую взаимодействует с SQLite , изолируя разработчика от базового SQL . [2]
Так же, как Cocoa Bindings обрабатывают многие обязанности контроллера в дизайне модель–представление–контроллер , Core Data обрабатывают многие обязанности модели данных. Среди прочих задач, он обрабатывает управление изменениями, сериализацию на диск, минимизацию занимаемой памяти и запросы к данным.
Core Data описывает данные с помощью высокоуровневой модели данных, выраженной в терминах сущностей и их взаимосвязей, а также запросов на выборку, которые извлекают сущности, соответствующие определенным критериям. Код может извлекать и обрабатывать эти данные на чисто объектном уровне, не беспокоясь о деталях хранения и извлечения. Объекты контроллера, доступные в Interface Builder, могут извлекать и обрабатывать эти сущности напрямую. В сочетании с привязками Cocoa пользовательский интерфейс может отображать множество компонентов модели данных без необходимости в фоновом коде.
Например: разработчик может писать программу для обработки vCards . Чтобы управлять ими, автор намеревается считывать vCards в объекты, а затем сохранять их в одном большом XML-файле. Используя Core Data, разработчик перетаскивает свою схему из конструктора данных в Xcode в окно конструктора интерфейса, чтобы создать графический интерфейс для своей схемы. Затем он может написать стандартный код Objective-C или Swift для чтения файлов vCard и помещения данных в управляемые сущности Core Data. С этого момента код автора управляет этими объектами Core Data, а не базовыми vCards. Подключение Saveпункта меню к соответствующему методу в объекте контроллера заставит контроллер проверить стек объектов, определить, какие объекты являются грязными , а затем переписать файл документа Core Data с этими изменениями.
Core Data организована в большую иерархию классов, хотя взаимодействие распространено только с небольшим набором из них.
Источники: [3] [2] [4] [5]
Core Data может сериализовать объекты в XML, двоичный файл или SQLite для хранения. [2] С выпуском Mac OS X 10.5 Leopard разработчики также могут создавать свои собственные атомарные типы хранилищ. Каждый метод имеет свои преимущества и недостатки, такие как удобство чтения человеком (XML) или более эффективное использование памяти (SQLite).
Эта часть Core Data похожа на исходную систему Enterprise Objects Framework (EOF), в которой можно писать довольно сложные запросы. В отличие от EOF, невозможно написать свой собственный SQL, так как базовое хранилище может не быть основано на SQL. Недавно хранилище Core Data для ODBC стало доступно в фреймворке ODBC. [6]
Схемы Core Data стандартизированы. Если у вас есть файл Xcode Data Model, вы можете свободно читать и записывать файлы в этом формате. Однако, в отличие от EOF, Core Data в настоящее время не предназначен для многопользовательского или одновременного доступа, если вы не используете фреймворк ODBC. [6]
Миграция схемы также нетривиальна, почти всегда требуя кода. Если другие разработчики имеют доступ к вашей модели данных и зависят от нее, вам может потребоваться предоставить код перевода версии в дополнение к новой модели данных, если ваша схема изменится.
Core Data во многом обязана своей конструкцией более раннему продукту NeXT — Enterprise Objects Framework (EOF). [7]
EOF был объектно-реляционным отображением для высокопроизводительных движков баз данных SQL, таких как Microsoft SQL Server и Oracle . Цель EOF была двоякой: во-первых, подключиться к движку базы данных и скрыть детали реализации; во-вторых, прочитать данные из реляционного формата и преобразовать их в набор объектов. Разработчики обычно взаимодействовали только с объектами, что упрощало разработку сложных программ за счет некоторой настройки для отображения данных на объекты. Объектная модель EOF была намеренно разработана для того, чтобы заставить полученные программы работать в документоподобной манере; пользователь мог редактировать данные локально в памяти, а затем записывать все изменения с помощью одной команды Save.
На протяжении всей своей истории EOF содержал ряд фрагментов полезного кода, которые в ином случае не были доступны в NeXTSTEP / OpenStep . Например, EOF требовал возможности отслеживать, какие объекты были грязными, чтобы система могла позже их записать. Это было представлено разработчику не только как система, похожая на документ, но и в форме неограниченного стека команд Undo, где каждая команда применялась к данным, представленным как отменяемое действие. Многие разработчики жаловались, что этот код управления состоянием был слишком полезен, чтобы быть изолированным в EOF, и позже он был перемещен в API Cocoa во время перехода на Mac OS X.
Первоначально не был переведен сам EOF. EOF использовался в основном вместе с другим продуктом эпохи OpenStep, WebObjects , который изначально был сервером приложений на основе Objective-C . В то время Apple занималась портированием WebObjects на язык программирования Java , и в рамках этого преобразования EOF стало намного сложнее использовать из Cocoa. И снова было много жалоб от сторонних разработчиков.
Одно из критических осознаний заключается в том, что система управления состоянием объектов в EOF на самом деле не имела ничего общего с реляционными базами данных. Тот же код мог использоваться и использовался разработчиками для управления графами других объектов. В этой роли действительно полезными частями EOF были те, которые автоматически создавали наборы объектов из необработанных данных, а затем отслеживали их. Именно эта концепция составляет основу Core Data.