Разобравшись в основных понятиях Core Data, можно начинать им пользоваться. Для простоты и удобства, здесь и далее, будет предполагаться, что NSPersistenceStoreCoordinator, NSManagedObjectContext, NSManagedObjectModel уже созданы, и к ним есть доступ. Модель, которая будет использоваться в примерах, выглядит следующим образом:

Модель данных

Типы данных свойств объектов особого значения для примеров не имеют. Модель взята из “детского набора инженера-генетика”, который позволяет в домашних условиях выращивать животных нечто, с одним телом, одной головой, некоторым количеством рук и ног. Каждая часть тела имеет определенные свойства.

Начать стоит, как обычно, с заполнения БД. Необходимо напомнить, что Core Data - это не БД. Просто мы испольуем ее возможность сохранения данных из Core Data в БД.

Объект - CoreData.
Задача - изучение параметров и возможностей.
Результат - получение общих понятий о возможностях и возможных применениях.

Итак. CoreData - что за зверь такой? Как говорит нам документация, это очень хороший и пушистый зверь, который всего лишь является надстройкой над конкретным хранилищем данных. а именно - над данными, которые хранятся в бинарном виде(CoreData-формат), XML, SQLite базе.

Что же все-таки позволяет сделать CoreData? Операции со сложными графами объектов, с множественными связями, валидацией, с возможностью осуществлять undo/redo операции на и… сохранять эти графы в некотором хранилище данных. Что получает от этого программист? Возможность не опускаться до уровня отщепенцев базы данных, не рассматривать проблему сериализации/десериализации, работая на уровне объектов.

Необходимо заметить, что CoreData справляется с этими задачами очень шустро, и не идет ни в какое сравнение по скорости и количеству кода с другими реализациями ORM под iPhone (будь то самописный ORM на основе SQLite, либо надстрока FMDB, либо SQLite Persistence Objects).

Кроме всего прочего, в SDK 3.0 появились специальные вспомогательные классы, позволяющие быстро интегрировать ввод/вывод данных, сохраненных с помощью CoreData. Так, при помощи NSFetchedResultsController можно без особых проблем использовать UITableView для отображения нескольких ТЫСЯЧ объектов.
Интересно? Читаем дальше …

Когда возникает необходимость создать в модели отношение «один ко многим»  (такое, как показано на рисунке),

то может показаться, что обратные отношения ставить незачем, как и при отношениях «один к одному» . И действительно, ваше приложение запустится и не будет падать из-за этого, хотя компилятор и выдаст вам Warning’и. Но не все так просто…

Многие, наверное, уже пробовали работать с CoreData и хотя бы краем уха слышали/краем глаза видели что-то о поддержке undo/redo для контекста объектов. Дело в том, что существуют механизмы, позволяющие при изменении объектов, унаследованных от NSManagedObject и находящихся в контексте NSManagedObjectContex, производить перемещение по т.н. контекстному графу при помощи методов undo и redo. Вершины этого графа создаются путем вызова у контекста метода processPendingChanges, после чего последующие изменения объектов в контексте можно откатить до их состояния на момент создания вершины методом undo. Также можно перемещаться между созданными вершинами, вызывая методы undo (к предыдущей вершине) или redo (к следующей вершине). За обработку и управление изменениями отвечает undoManager - объект класса NSUndoManager, который есть у объекта- контекста. Сдесь небольшое уточнение - есть, если только вы программируете под Mac OS. В iPhone SDK undoManager не инициализируется при инициализации контекста!

[context undoManager] == nil;// == YES !!!!!!!!