Core Data es un marco de trabajo de persistencia y gráficos de objetos proporcionado por Apple en los sistemas operativos macOS e iOS . Fue introducido en Mac OS X 10.4 Tiger e iOS con iPhone SDK 3.0. [1] Permite que los datos organizados por el modelo de entidad-atributo relacional se serialicen en almacenes XML , binarios o SQLite . Los datos se pueden manipular utilizando objetos de nivel superior que representan entidades y sus relaciones. Core Data administra la versión serializada, proporcionando administración del ciclo de vida de los objetos y gráficos de objetos , incluida la persistencia . Core Data interactúa directamente con SQLite , aislando al desarrollador del SQL subyacente . [2]
De la misma forma que Cocoa Bindings se encarga de muchas de las tareas del controlador en un diseño modelo-vista-controlador , Core Data se encarga de muchas de las tareas del modelo de datos. Entre otras tareas, se encarga de la gestión de cambios, la serialización en disco, la minimización del uso de memoria y las consultas a los datos.
Core Data describe los datos con un modelo de datos de alto nivel expresado en términos de entidades y sus relaciones, además de solicitudes de búsqueda que recuperan entidades que cumplen criterios específicos. El código puede recuperar y manipular estos datos en un nivel puramente de objeto sin tener que preocuparse por los detalles de almacenamiento y recuperación. Los objetos de controlador disponibles en Interface Builder pueden recuperar y manipular estas entidades directamente. Cuando se combina con enlaces de Cocoa, la interfaz de usuario puede mostrar muchos componentes del modelo de datos sin necesidad de código de fondo.
Por ejemplo: un desarrollador podría estar escribiendo un programa para manejar vCards . Para administrarlas, el autor pretende leer las vCards en objetos y luego almacenarlas en un solo archivo XML más grande. Usando Core Data, el desarrollador arrastraría su esquema desde el diseñador de datos en Xcode a una ventana de creación de interfaz para crear una GUI para su esquema. Luego, podría escribir código Objective-C o Swift estándar para leer archivos vCard y colocar los datos en entidades administradas por Core Data. A partir de ese punto, el código del autor manipula estos objetos de Core Data, en lugar de las vCards subyacentes. Conectar el Saveelemento de menú al método apropiado en el objeto controlador indicará al controlador que examine la pila de objetos, determine qué objetos están sucios y luego vuelva a escribir un archivo de documento de Core Data con estos cambios.
Core Data está organizado en una gran jerarquía de clases, aunque la interacción solo prevalece con un pequeño conjunto de ellas.
Fuentes: [3] [2] [4] [5]
Core Data puede serializar objetos en XML, binarios o SQLite para su almacenamiento. [2] Con el lanzamiento de Mac OS X 10.5 Leopard , los desarrolladores también pueden crear sus propios tipos de almacenamiento atómico personalizados . Cada método tiene ventajas y desventajas, como ser legible por humanos (XML) o más eficiente en el uso de la memoria (SQLite).
Esta parte de Core Data es similar al sistema Enterprise Objects Framework (EOF) original, en el sentido de que se pueden escribir consultas bastante sofisticadas. A diferencia de EOF, no es posible escribir su propio SQL, ya que el almacenamiento subyacente puede no estar basado en SQL. Recientemente, el almacenamiento de Core Data para ODBC se ha puesto a disposición en el marco ODBC. [6]
Los esquemas de Core Data están estandarizados. Si tiene el archivo de modelo de datos de Xcode, puede leer y escribir archivos en ese formato libremente. Sin embargo, a diferencia de EOF, Core Data no está diseñado actualmente para el acceso simultáneo o multiusuario a menos que utilice el marco ODBC. [6]
La migración de esquemas tampoco es trivial y casi siempre requiere código. Si otros desarrolladores tienen acceso a su modelo de datos y dependen de él, es posible que deba proporcionar un código de traducción de la versión además de un nuevo modelo de datos si su esquema cambia.
Core Data debe gran parte de su diseño a un producto anterior de NeXT , Enterprise Objects Framework (EOF). [7]
EOF era un modelo relacional de objetos para motores de bases de datos SQL de alta gama, como Microsoft SQL Server y Oracle . El propósito de EOF era doble: primero, conectarse al motor de base de datos y ocultar los detalles de implementación; segundo, leer los datos del formato relacional y traducirlos a un conjunto de objetos. Los desarrolladores normalmente interactuaban solo con los objetos, lo que simplificaba el desarrollo de programas complejos, a costa de cierta configuración para asignar los datos a los objetos. El modelo de objetos EOF fue diseñado deliberadamente para hacer que los programas resultantes funcionaran de manera similar a un documento; el usuario podía editar los datos localmente en la memoria y luego escribir todos los cambios con un solo comando Guardar.
A lo largo de su historia, EOF contenía una serie de fragmentos de código útil que no estaban disponibles en NeXTSTEP / OpenStep . Por ejemplo, EOF requería la capacidad de rastrear qué objetos estaban sucios para que el sistema pudiera escribirlos más tarde. Esto se presentó al desarrollador no solo como un sistema similar a un documento, sino también en forma de una pila de comandos de deshacer ilimitados, con cada comando aplicado a los datos representados como una acción que se podía deshacer. Muchos desarrolladores se quejaron de que este código de gestión de estados era demasiado útil para estar aislado en EOF, y más tarde se trasladó a la API de Cocoa durante la transición a Mac OS X.
Al principio, lo que no se tradujo fue el propio EOF. EOF se utilizó principalmente junto con otro producto de la era OpenStep, WebObjects , que era un servidor de aplicaciones basado originalmente en Objective-C . En ese momento, Apple estaba en proceso de trasladar WebObjects al lenguaje de programación Java y, como parte de esta conversión, EOF se volvió mucho más difícil de usar desde Cocoa. Una vez más, hubo muchas quejas entre los desarrolladores externos.
Un aspecto fundamental es que el sistema de gestión de estados de objetos de EOF no tenía nada que ver con bases de datos relacionales. Los desarrolladores podían utilizar el mismo código para gestionar gráficos de otros objetos. En este sentido, las partes realmente útiles de EOF eran las que construían automáticamente los conjuntos de objetos a partir de los datos sin procesar y luego realizaban un seguimiento de ellos. Este concepto es el que constituye la base de Core Data.