Core Data: Фреймворк постоянного хранения данных Apple

Введение

Core Data — это объектный граф и фреймворк постоянного хранения данных, предоставляемый Apple в операционных системах macOS и iOS. Он был представлен в Mac OS X 10.4 Tiger и iOS с iPhone SDK 3.0. Он позволяет сериализовать данные, организованные по реляционной модели сущность-атрибут, в хранилища XML, бинарные или SQLite. Данными можно управлять, используя объекты более высокого уровня, представляющие сущности и их взаимосвязи. Core Data управляет сериализованной версией данных, обеспечивая жизненный цикл объектов и управление объектными графами, включая постоянное хранение. Core Data напрямую взаимодействует с SQLite, ограждая разработчика от базового SQL. Подобно тому, как Cocoa Bindings берет на себя многие обязанности контроллера в архитектуре «модель-представление-контроллер», Core Data берет на себя многие обязанности модели данных. Среди прочих задач, он обрабатывает управление изменениями, сериализацию на диск, минимизацию занимаемой памяти и выполнение запросов к данным.

Форматы хранения

Core Data может сериализовать объекты в XML, двоичный формат или SQLite для хранения. Схемы данных Core Data стандартизированы. Если у вас есть файл модели данных Xcode, вы можете свободно читать и записывать файлы в этом формате. Однако, в отличие от EOF, Core Data в настоящее время не рассчитана на многопользовательский или одновременный доступ, если вы не используете фреймворк ODBC. Миграция схемы также является непростой задачей и почти всегда требует написания кода. Если другие разработчики имеют доступ к вашей модели данных и зависят от неё, при изменении схемы вам может потребоваться предоставить код преобразования версий в дополнение к новой модели данных.

История и генезис

Core Data во многом обязан своим дизайном более раннему продукту NeXT, Enterprise Objects Framework (EOF). EOF был объектно-реляционным отображением для высокопроизводительных СУБД SQL, таких как Microsoft SQL Server и Oracle. Цель EOF была двойной: во-первых, обеспечить подключение к движку базы данных и скрыть детали реализации; во-вторых, извлекать данные из реляционного формата и преобразовывать их в набор объектов. Разработчики обычно взаимодействовали только с объектами, что упрощало разработку сложных программ, но требовало определенной настройки для сопоставления данных с объектами. Объектная модель EOF была намеренно разработана таким образом, чтобы результирующие программы работали подобно документу: пользователь мог редактировать данные локально в памяти, а затем записывать все изменения одной командой "Сохранить". На протяжении всей своей истории EOF содержал ряд полезных фрагментов кода, недоступных в NeXTSTEP/OpenStep. Например, EOF требовал возможности отслеживать "грязные" объекты, чтобы система могла впоследствии их записать. Это было представлено разработчику не только как система, подобная работе с документом, но и в виде неограниченного стека команд "Отменить", где каждая команда, применяемая к данным, представляла собой отменяемое действие. Многие разработчики жаловались, что этот код управления состоянием был слишком полезен, чтобы быть изолированным в EOF, и позже он был перенесен в Cocoa API во время перехода на Mac OS X. Изначально сам EOF не был переведен. EOF использовался в основном вместе с другим продуктом эпохи OpenStep, WebObjects, который являлся сервером приложений, изначально основанным на Objective-C. В то время Apple переносила WebObjects на язык программирования Java, и в рамках этого преобразования работа с EOF из Cocoa стала значительно сложнее. Вновь возникли многочисленные жалобы со стороны сторонних разработчиков. Важным осознанием стало то, что система управления состоянием объектов в EOF на самом деле не имела отношения к реляционным базам данных. Тот же код мог быть и использовался разработчиками для управления графами других объектов. В этом качестве наиболее полезными частями EOF были те, которые автоматически создавали наборы объектов из исходных данных и затем отслеживали их. Именно эта концепция лежит в основе Core Data.

Core Data owes much of its design to an earlier NeXT product, Enterprise Objects Framework (EOF). EOF was an object relational mapping for high end SQL database engines such as Microsoft SQL Server and Oracle. EOF's purpose was twofold: first, to connect to the database engine and hide the implementation details; second, to read the data out of the relational format and translate that into a set of objects. Developers typically interacted only with the objects, which simplified development of complex programs, at the cost of some setup to map the data to the objects. The EOF object model was deliberately designed to make the resulting programs work in a document like fashion; the user could edit the data locally in memory, and then write out all changes with a single Save command. Throughout its history, EOF contained a number of bits of useful code that were not otherwise available under NeXTSTEP/OpenStep. For instance, EOF required the ability to track which objects were dirty so the system could later write them out. This was presented to the developer not only as a document like system, but also in the form of an unlimited Undo command stack, with each command applied to the data represented as an undoable action. Many developers complained that this state management code was far too useful to be isolated in EOF, and it was later moved into the Cocoa API during the transition to Mac OS X. Initially, what was not translated was EOF itself. EOF was used primarily along with another OpenStep era product, WebObjects, which was an application server originally based on Objective C. At the time, Apple was in the process of porting WebObjects to the Java programming language, and as part of this conversion, EOF became much more difficult to use from Cocoa. Once again, there was considerable complaining among 3rd party developers. One critical realization is that the object state management system in EOF did not really have anything to do with relational databases. The same code could be, and was, used by developers to manage graphs of other objects as well. In this role, the really useful parts of EOF were those that automatically built the object sets from the raw data, and then tracked them. It is this concept that forms the basis of Core Data.