 | |
| Developer(s) | Apple Inc. |
|---|---|
| Stable release | 3.2.0 |
| Operating system | macOS,iOS,tvOS,watchOS |
| Type | System Utility |
| License | Proprietary |
| Website | Apple Developer Core Data Programming Guide |
Core Data is anobject graph andpersistence framework provided byApple in themacOS andiOSoperating systems. It was introduced inMac OS X 10.4 Tiger andiOS with iPhone SDK 3.0.[1] It allows data organized by therelational entity–attribute model to beserialized intoXML,binary, orSQLite stores. The data can be manipulated using higher level objects representing entities and their relationships. Core Data manages the serialized version, providingobject lifecycle andobject graph management, includingpersistence. Core Data interfaces directly withSQLite, insulating the developer from the underlyingSQL.[2]
Just asCocoa Bindings handle many of the duties of the controller in amodel–view–controller design, Core Data handles many of the duties of the data model. Among other tasks, it handles change management, serializing to disk,memory footprint minimization and queries against the data.
Core Data describes data with a high level data model expressed in terms of entities and their relationships plus fetch requests that retrieve entities meeting specific criteria. Code can retrieve and manipulate this data on a purely object level without having to worry about the details of storage and retrieval. The controller objects available inInterface Builder can retrieve and manipulate these entities directly. When combined with Cocoa bindings the UI can display many components of the data model without needing background code.
For example: a developer might be writing a program to handlevCards. In order to manage these, the author intends to read the vCards into objects, and then store them in a single larger XML file. Using Core Data the developer would drag theirschema from the data designer inXcode into an interface builder window to create a GUI for their schema. They could then write standardObjective-C orSwift code to read vCard files and put the data into Core Data managed entities. From that point on the author's code manipulates these Core Data objects, rather than the underlying vCards. Connecting theSave menu item to the appropriate method in the controller object will direct the controller to examine the object stack, determine which objects aredirty, and then re-write a Core Data document file with these changes.
Core Data is organized into a large hierarchy of classes, though interaction is only prevalent with a small set of them.
| Name | Use | Key methods |
|---|---|---|
| NSManagedObject |
|
|
| NSManagedObjectContext |
|
|
| NSManagedObjectModel |
|
|
| NSFetchRequest |
|
|
| NSPersistentStoreCoordinator |
|
|
| NSPredicate |
|
|
Core Data can serialize objects into XML, binary, orSQLite for storage.[2] With the release ofMac OS X 10.5 Leopard, developers can also create their own customatomic store types. Each method carries advantages and disadvantages, such as being human readable (XML) or more memory efficient (SQLite).
This portion of Core Data is similar to the originalEnterprise Objects Framework (EOF) system, in that one can write fairly sophisticated queries. Unlike EOF, it is not possible to write your own SQL, as the underlying store may not be SQL-based. Recently, Core Data store for ODBC has been made available inODBC framework.[6]
Core Data schemas are standardized. If you have the Xcode Data Model file, you can read and write files in that format freely. Unlike EOF, though, Core Data is not currently designed for multiuser or simultaneous access unless you use ODBC framework.[6]
Schema migration is also non-trivial, almost always requiring code. If other developers have access to and depend upon your data model, you may need to provide version translation code in addition to a new data model if your schema changes.
Core Data owes much of its design to an earlierNeXT product,Enterprise Objects Framework (EOF).[7]
EOF was anobject-relational mapping for high-end SQL database engines such asMicrosoft SQL Server andOracle. 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 underNeXTSTEP/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 theCocoa API during the transition toMac OS X.
Initially, what was not translated was EOF itself. EOF was used primarily along with another OpenStep-era product,WebObjects, which was anapplication server originally based onObjective-C. At the time, Apple was in the process of porting WebObjects to theJava 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.
| Products |
| ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Services |
| ||||||||||||||||||||
| Companies |
| ||||||||||||||||||||
| Related | |||||||||||||||||||||
| People | |||||||||||||||||||||
| |||||||||||||||||||||
| Versions |
| ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Applications |
| ||||||||||
| Utilities |
| ||||||||||
| Technologies & User Interface |
| ||||||||||
| |||||||||||
