Under the Hood of Core Data - Core Data - page 1

CHAPTER 1

Under the Hood of Core Data

Part of the barrier to entering the world of Core Data is that it is perceived as
having a very steep learning curve. Looking at the code samples that Apple
provides for developers, you might at first glance agree with that evaluation.

In my experience of working with and writing persistence layers for various
languages, I am constantly amazed at how simple and elegant the Core Data
API is. There is very little overlap in functionality between the individual pieces
of Core Data—no wasted space or unnecessary redundancy. Because Core
Data is built on the infrastructure of Objective-C and Core Foundation, it
does not seek to duplicate functionality that already exists in other parts of
the overall API but instead uses that functionality to its full extent.

In this chapter, we go through the key pieces of Core Data and remove some
of the mysticism that surrounds them. We will also rewrite the sample code
from Apple in order to present it in a much smaller and easier-to-maintain
package. By the end of this chapter, you'll have a much higher comfort level
and will be able to understand what all of that sample code does.

The Core Data API, or stack as it is commonly called, consists of three primary
pieces: the NSManagedObjectModel , the NSPersistentStoreCoordinator , and the NSManage-
dObjectContext . All of these work together to allow a program to retrieve and
store NSManagedObject instances. In most situations, the program will access
the NSManagedObjectContext only once the stack has been created. It is possible
to access the other components of the stack, but it is rarely necessary.

1.1 NSManagedObjectModel

The first part of our exploration of the components of Core Data is the portion
of the framework that is the least-accessed: the NSManagedObjectModel . The
NSManagedObjectModel can be considered a compiled, binary version of the data
model that we create in Xcode. When we say that we are manipulating the