Objective-C Fundamentals

Core Data objects
231
In Xcode you can create a new project configured to use Core Data as the storage
mechanism, which involves importing the CoreData.framework. Projects configured
to use Core Data also create the Xcode data model that’s used to define what your
data looks like, also known as its schema.
12.2 Core Data objects
The functionality of Core Data is achieved through four distinct objects that compose
what is known as the Core Data stack. These are the four major objects that make up Core
Data’s functionality. We investigate the purpose of each in the next several sections. The
singular point of access is through the managed object context, discussed next, so if
you’re less concerned with the nuts and bolts of the system, you don’t need to be too
concerned about the persistent store coordinator and the persistent object store.
12.2.1 Managed object context
NSManagedObjectContext is the object that you work with to add, access, modify, or
delete objects. When you access a single element out of a managed object context, an
NSManagedObject or a subclass of it is returned. In the Person example, a returned
NSManagedObject could be a Person object. You aren’t required to create subclasses
for every entity, though. You can also work directly with NSManagedObject instances, as
you’ll see in this chapter’s demo application.
When you’re working with an NSManagedObject retrieved from your managed
object context, a good way to think of how the logic works is to compare it to a text
file: if you open a text file, change a whole bunch of the text, add some, remove some,
nothing matters unless and until you save it. So when you retrieve an NSManaged-
Object from your managed object context, the changes you make to it are applied to
the database only when you tell the managed object context to save it. We get into the
details of these activities later in this chapter, but the important point is to know that
by using the managed object context, you can add, retrieve, and save NSManaged-
Objects or your custom subclasses.
12.2.2 Persistent store coordinator
In the stack, you work exclusively with the managed object context, and while a complex
application may have several managed object contexts, all Core Data–based projects
have only a single store coordinator. The persistent store coordinator sits between
a managed object context and a persistent object store. You can think of it as the key
holder to the databases. The managed object context must ask the persistent object
coordinator if the requested access modification or deletion is allowed. It’s important
that a storage controller contains lots of checks to validate actions by its user, which is
why you use only a single persistent store coordinator. If more than one coordinator
exists, conflicting access to the database may occur. The persistent store coordinator
manages all of the logic necessary to safely access and modify database tables.