Jump to content

Core Data

From Alfawiki
Core Data
Company typeFramework
IndustrySoftware development
Founded2005; 21 years ago (2005)
FounderApple Inc.
Headquarters
Cupertino, California
,
United States
ProductsObject graph management and data persistence framework
OwnerApple Inc.
Websitedeveloper.apple.com/documentation/coredata

Core Data is an object graph and persistence framework created by Apple Inc for use on macOS and iOS platforms. Launched with Mac OS X 10.4 Tiger and iOS SDK 3.0, it allows data structured according to the relational entity–attribute model to be stored in formats such as XML, binary, or SQLite. Core Data operates by managing data through high-level objects that represent entities and their interconnections, overseeing object lifecycle, graph management, and data persistence. It communicates directly with SQLite, abstracting the underlying SQL operations from developers.

Much like how Cocoa Bindings support controller functions within a model–view–controller design pattern, Core Data handles numerous responsibilities related to the data model, including tracking changes, saving to disk, optimizing memory usage, and executing queries.

Usage

Core Data relies on a high-level data schema defined by entities, relationships, and fetch requests that retrieve entities based on specified conditions. Developers interact with data exclusively as objects without concern for storage mechanics. Controller objects built in Interface Builder can link directly to these entities, and when used alongside Cocoa bindings, the user interface can mirror the data model with minimal programming effort.

For example, when working with vCards, a developer can employ Core Data to convert vCard details into managed entities using Xcode’s data modeling tools and Interface Builder. Reading vCards into Core Data objects is accomplished via standard Objective-C or Swift code. Afterward, all manipulations are performed on these objects rather than raw vCard data. UI elements such as a Save menu option can prompt Core Data to detect modified ("dirty") objects and commit those changes to persistent storage.

Although Core Data encompasses many classes, developers typically engage mainly with the following key components:

Class Purpose Primary methods
NSManagedObject
  • Represents individual data records
  • Accesses attributes
  • -entity
  • -valueForKey:
  • -setValue:forKey:
NSManagedObjectContext
  • Oversees changes and actions on objects
  • -executeFetchRequest:error:
  • -save
NSManagedObjectModel
  • Defines the data structure and storage schema
  • -entities
  • -fetchRequestTemplateForName:
  • -setFetchRequestTemplate:forName:
NSFetchRequest
  • Specifies data retrieval requests
  • -setEntity:
  • -setPredicate:
  • -setFetchBatchSize:
NSPersistentStoreCoordinator
  • Coordinates persistence mechanisms
  • -addPersistentStoreWithType:configuration:URL:options:error:
  • -persistentStoreForURL:
NSPredicate
  • Expresses query filters and conditions
  • +predicateWithFormat:
  • -evaluateWithObject:

Storage formats

Core Data supports serialization of managed objects into XML, binary, or SQLite formats. Since the release of Mac OS X 10.5 Leopard, developers have been able to implement custom atomic store types as well. Each format presents different advantages; for instance, XML offers human readability whereas SQLite provides better memory efficiency.

This functionality is reminiscent of the original Enterprise Objects Framework (EOF), which facilitated advanced querying capabilities. However, unlike EOF, Core Data does not allow custom SQL queries because its underlying stores may not be based on SQL engines. Recently, an ODBC-backed Core Data store has been introduced within the ODBC framework.

Core Data uses standardized schemas; thanks to the Xcode Data Model file format, these schemas can be freely read from and written to. Unlike EOF, Core Data is not inherently designed for multiuser or concurrent access scenarios unless integrated with the ODBC framework.

Schema migration remains a challenging process that generally requires explicit coding efforts. When multiple developers depend on a shared data model, it is often necessary to provide version translation logic alongside updated data models whenever schema modifications occur.

History and origins

The architecture of Core Data is largely influenced by an earlier product from NeXT, known as the Enterprise Objects Framework (EOF).

EOF functioned as an object-relational mapping solution tailored for enterprise-level SQL databases such as Microsoft SQL Server and Oracle. Its primary goal was to shield developers from the complexities of database interactions by transforming relational data into object representations, thereby streamlining the development of sophisticated applications. EOF's object model facilitated document-style workflows, enabling users to modify data locally before committing all changes simultaneously.

Among EOF's distinctive features were advanced state management capabilities absent in other NeXTSTEP/OpenStep components. These included monitoring altered ("dirty") objects and maintaining an extensive Undo stack that captured reversible operations. The practical benefits of this state management led to its adoption within the Cocoa API during Apple's shift to Mac OS X.

Initially, EOF was not ported directly; it primarily served the OpenStep-era WebObjects, an application server originally developed with Objective-C. However, when Apple migrated WebObjects to Java, integrating EOF with Cocoa became more challenging, which caused frustration among developers.

A crucial realization was that EOF's object state management operated independently from relational databases. This mechanism managed object graphs beyond database contexts by automatically generating and tracking collections of objects derived from raw data—a principle that forms the foundation of Core Data.

References

External links

Retrieved from "https://www.alfawiki.org/index.php?title=Core_Data&oldid=22568"