Core Data Stack: The Working Parts

Learning Core Data can be a bit of a doozy with all the technical sounding jargon. Before jumping into how to use Core Data, getting to know a little background of the players in the framework can prove to be beneficial.

Apple’s Diagram on the Core Data Stack

If this diagram doesn’t make sense, don’t worry about. We’re about to go through this stack in detail.

  1. Entity Description ( NSEntityDescription )
    TLDR: It’s the Core Data equivalent to a Class Description
    You can think of an entity description as a class description. Just like how you would make a Class for Dog and give it name, weight, and breed Properties, you would make an Entity for Dog and give it name, weight, and breed Attributes. The Entity Description is basically the blueprint of your entity and is used to make instances of those Entities.
  2. Managed Object ( NSManagedObject )
    TLDR: It’s the Core Data equivalent to an instance of a class or an object
    Managed Objects are the instances of the Entities. Just like how you would make multiple instances of a Person class, you would make multiple instances of a Person entity, except the instances of the Person entity, as you can guess by the name, will be managed by Core Data.
  3. Managed Object Model ( NSManagedObjectModel )
    TLDR: It’s a collection of Entity Descriptions from your Data Model
    The Managed Object Model is essentially your Data Model file (.xcdatamodeld). Every entity you define in your Data Model will be available as an Entity Description thanks to the Managed Object Model
  4. Managed Object Context ( NSManagedObjectContext )
    TLDR: It’s a box that holds your managed objects
    The Managed Object Context is the context in which your Managed Objects live. Basically, it’s a box that holds your managed objects. You can save your objects by calling save on it. You can also fetch your objects from this box. This metaphor falls flat when you ask “What about if you add new objects? Will they be saved automatically?” Well, no. You’ll have to save the box again to add the changes. More on this on the Core Data Metaphors post.
  5. Persistent Store ( NSPersistentStore ) & Persistent Object Store ( NSPersistentObjectStore)
    TLDR: Persistent Store is the representation of your Data Store file
    You don’t need to know too much about Persistent Stores and Persistent Object Stores. While they’re not the same thing, in general, you can use them interchangeably. When Core Data saves your Managed Object Context, it saves it to .storeData file(s). All you really need to know is that Persistent Stores are the representations of these files. If you really need to know what Persistent Object Stores are, they’re simply maps of where your objects in code are stored in the Persistent Stores.
  6. Persistent Store Coordinator ( NSPersistentStoreCoordinator )
    TLDR: Persistent Store Coordinator manages the Persistent Stores and allows you to treat all the data stores as a single unified store
    Even though you’ll barely ever touch the Persistent Store Coordinator, it is the backbone of Core Data. It’s main job is to present to its Managed Object Contexts the Persistent Stores as “a single unified store.” When you save or fetch from a Managed Object Context, the Persistent Store Coordinator is the link that allows the action to be taken.

Cool, so that was a lot to digest. Here’s a diagram that’ll hopefully help explain how everything is connected.

Excuse my inability to draw things in Sketch

So let’s go from Left to Right. The Managed Object Model is pretty much your data model file. It is a collection of Entity Descriptions based on the entities and their details you specified in the Data Model.

Data Model file

The Managed Object Model provides us the Entity Descriptions from which we instantiate our Managed Objects. All our Managed Objects live in the Managed Object Context.

We can save the Managed Objects in Managed Object Context to the Store Files (Persistent Stores). We can also fetch objects from the Managed Object Context. It saves to and fetches from a single storage unit. What actually is happening, however, is that the Persistent Store Coordinator is presenting all the store files as one unit.

Aaaaand that’s it. Those are the players and working parts of Core Data!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.