Before we delve into the first project and add Core Data to it, we'll take a look at how Core Data actually works, what it is, and what it isn't. In order to make efficient use of Core Data, it's essential that you know what you're working with.
When you work with Core Data, you're actually utilizing a stack of layers that starts with managed objects and ends with a data store. This is often an SQLite database but there are different storage options you can use with Core Data, depending on your application needs. Let's take a quick look at the layers involved with Core Data and discuss their roles in an application briefly:
At the top right of this diagram is the NSManagedObject class. When you are working with Core Data, this is the object you'll interact with most often since it's the base class for all Core Data models your app contains. For instance, in the app we will build, the family member and movie models are subclasses of NSManagedObject.
Each managed object belongs to an NSManagedObjectContext. The managed object context is responsible for communicating with the persistent store coordinator. Often, you'll only need a single managed object context and a single Persistent Store Coordinator. However, it is possible for you to use multiple persistent store coordinators and multiple managed object contexts. It's even possible to have multiple managed object contexts for the same Persistent Store Coordinator.
A setup like this can be particularly useful if you're performing costly operations on your managed objects, for example if you're importing or synchronizing large amounts of data. We'll stick to using a single managed object context and a single Persistent Store coordinator because we simply don't have the need for more.
The Persistent Store coordinator is responsible for communicating to the Persistent Store. In most scenarios, the Persistent Store uses SQLite as its underlying storage database. However, you can also use other types of storage, such as an in-memory database. Using an in-memory database is especially useful if you're writing unit tests or if your app has no need for long-term storage. More information on testing can be found in Chapter 21, Ensuring App Quality with Tests.
If you've worked with MySQL, SQLite, or any other relational database before, it is tempting to think of Core Data as a layer on top of a relational database. Although this isn't entirely false since Core Data can use SQLite as its underlying storage, Core Data does not work the same as using SQLite directly; it's an abstraction on top of this.
One example of a difference between SQLite and Core Data is the concept of primary keys. Core Data doesn't allow you to specify your own primary keys. Also, when you define relationships, you don't use object IDs or other keys; you simply define the relationship and Core Data will figure out how to store this relationship in the underlying database. We will cover more on this subject later. It's important to be aware of the fact that, if you try to translate your SQLite experience to Core Data, you will run into issues, simply because Core Data is not SQLite. It just so happens that SQLite is one of the ways that data can be stored.
Now that you have an overview of the Core Data stack and where all the parts involved with its usage belong, let's add the Core Data stack to the FamilyMovies application.