Core Data — ключови понятия, NSManagedObject и архитектура

Какво е Core Data?

Core Data — е рамка за управление на обектен граф и устойчивост на данни, част от Cocoa Touch SDK на Apple. Тя предоставя обектно-ориентиран интерфейс за работа с данни: разработчикът работи с обекти (Entity), атрибути и връзки (Relationship), а Core Data преобразува тези обекти в записи на релационна база данни под капака.

Core Data беше представен в Mac OS X 10.4 Tiger (2005) за macOS и пренесен в iOS 3.0 (2009). За повече от 20 години рамката еволюира от прост слой на абстракция над SQLite до пълен стек с поддръжка на облачна синхронизация чрез NSPersistentCloudKitContainer, многонишково изпълнение чрез автоматично управление на контексти и асинхронно зареждане чрез Swift Concurrency.

Според проучване на iOS разработчици от Slack Community (2025), Core Data се използва в 68% от търговските iOS приложения за локално съхранение на данни. Въпреки критиките за сложност и многослойност, рамката остава стандарт за Apple приложения благодарение на тясната интеграция със системата, нулевата цена (вградена в SDK) и поддръжката на iCloud синхронизация.

Core Data не е база данни

Често срещано погрешно схващане — да се счита Core Data за база данни. Рамката не изпълнява директно SQL заявки и не е СУБД. Core Data е слой за управление на обекти (object graph management), който може да използва SQLite, Binary или In-Memory за устойчивост. Аналогия: Core Data е като ORM като Hibernate или Entity Framework, но за екосистемата на Apple, а SQLite под него — като MySQL под Hibernate.

Архитектура на Core Data: стекове и компоненти

Стекът на Core Data се състои от четири взаимосвързани компонента: NSManagedObjectModel (схема на данни), NSPersistentStoreCoordinator (координатор на хранилища), NSManagedObjectContext (работен контекст) и NSPersistentContainer (единен контейнер, обединяващ и трите от iOS 10). NSPersistentContainer автоматизира създаването и конфигурирането на стека.

Всеки компонент изпълнява строго определена функция. NSManagedObjectModel зарежда .xcdatamodeld файла с описание на обекти. NSPersistentStoreCoordinator свързва модела с физическия файл на хранилището (SQLite). NSManagedObjectContext предоставя временна област за работа с обекти. Контейнерът обединява всичко в едно извикване за инициализация.

Типове хранилища на Core Data

SQLite (NSSQLiteStoreType) — стандартно хранилище, използвано в повечето приложения. Данните се съхраняват в един .sqlite файл с поддръжка на ACID транзакции. Binary (NSBinaryStoreType) — хранилище в двоичен формат за малки набори от данни (до няколкостотин обекта). In-Memory (NSInMemoryStoreType) — временно хранилище в RAM без запазване на диск, използва се за тестове и кеш.

Изборът на хранилище се задава с един ред при инициализация на NSPersistentStoreDescription. Разработчикът може да превключи хранилището от SQLite на In-Memory за unit тестове или на CloudKit за iCloud синхронизация без промяна на кода за работа с обекти — Core Data абстрахира разликата между типовете хранилища чрез единен API на контекста.

NSManagedObject и NSManagedObjectContext

NSManagedObject — базов клас за всички Core Data обекти, представляващ един запис на обект. Всеки управляван обект има уникален NSManagedObjectID (постоянен идентификатор), обвързан е с контекст и проследява промените си чрез KVO (Key-Value Observing). Разработчикът създава подкласове на NSManagedObject за дефиниране на типизирани свойства на обекта.

NSManagedObjectContext — централен компонент на Core Data, предоставящ работна област за всички операции с обекти. Контекстът проследява добавянето, изтриването и промените на обекти (change tracking), поддържа отмяна на операции чрез undoManager и автоматично обединява промени от други контексти при получаване на известия за запазване.

Нишкова безопасност на контекстите

Правило за частни опашки: NSManagedObjectContext се създава с тип .privateQueueConcurrencyType или .mainQueueConcurrencyType. Главният контекст е обвързан с основната UI нишка, частните контексти се изпълняват на фонови опашки. Всеки контекст трябва да се използва само в своята опашка — достъп до управляван обект от друга нишка причинява срив. parentContext позволява организиране на йерархия от контексти за асинхронен запис.

struct CoreDataStack {
    let container: NSPersistentContainer

    init(name: String) {
        container = NSPersistentContainer(name: name)
        container.loadPersistentStores { _, error in
            if let error = error {
                fatalError("Failed to load store: \(error)")
            }
        }
        container.viewContext.automaticallyMergesChangesFromParent = true
    }

    func backgroundContext() -> NSManagedObjectContext {
        let context = container.newBackgroundContext()
        context.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
        return context
    }
}

NSPersistentContainer автоматично създава viewContext (main queue) и предоставя newBackgroundContext() за фонови операции. Свойството automaticallyMergesChangesFromParent = true кара viewContext автоматично да поема промени от фонови контексти при тяхното запазване, актуализирайки UI без ръчно повторно извличане на данни.

Persistent Store и връзка с SQLite

NSPersistentStoreCoordinator управлява физическото хранилище на данни: отваря файла, създава SQLite таблици на базата на модела, изпълнява миграции при промяна на схемата. При инициализация на NSPersistentStoreDescription с тип NSSQLiteStoreType, Core Data създава SQLite файл със схема, съответстваща на .xcdatamodeld модела.

Core Data не използва стандартни SQL заявки чрез SELECT/INSERT/UPDATE. Вместо това генерира вътрешни SQL команди на базата на модела и заявки чрез NSFetchRequest. Разработчикът може да активира SQL регистрация чрез аргумента за стартиране -com.apple.CoreData.SQLDebug 1 за отстраняване на грешки в производителността на заявки.

Миграции на Core Data

Лека миграция (Lightweight Migration) — автоматичен процес на актуализиране на SQLite схемата при добавяне на нови атрибути, промяна на optional/required или преименуване с помощта на renamingID. Тежка миграция се изисква при коренни промени на схемата, като обединяване или разделяне на обекти, и се изпълнява чрез персонализиран NSMigrationManager.

let description = NSPersistentStoreDescription()
description.url = FileManager.default
    .urls(for: .documentDirectory, in: .userDomainMask)
    .first?
    .appendingPathComponent("Model.sqlite")
description.setOption(true as NSNumber,
    forKey: NSMigratePersistentStoresAutomaticallyOption)
description.setOption(true as NSNumber,
    forKey: NSInferMappingModelAutomaticallyOption)

let container = NSPersistentContainer(name: "AppModel")
container.persistentStoreDescriptions = [description]
container.loadPersistentStores { _, error in
    if let error = error { print("Migration error: \(error)") }
}

Конфигурирането на автоматична миграция чрез NSMigratePersistentStoresAutomaticallyOption и NSInferMappingModelAutomaticallyOption позволява на Core Data самостоятелно да актуализира SQLite файла при добавяне на атрибути или обекти в нова версия на модела. Ако миграцията не е възможна, координаторът на хранилище хвърля грешка с описание на причината — разработчикът трябва да реализира персонализирана миграция чрез NSMigrationManager.

Core Data на практика: код и примери

NSFetchRequest — основният инструмент за извличане на обекти от Core Data. Заявката съдържа име на обект, предикат (филтър), сортировки, лимит и отместване (offset). Резултатът се връща като масив от NSManagedObject или типизирани подкласове. NSPredicate поддържа сложни условия с AND, OR, IN, LIKE и подзаявки.

NSBatchDeleteRequest — ефективен начин за масово изтриване на обекти без зареждане на всеки в паметта. Заявката се изпълнява на ниво SQLite, заобикаляйки managed object context, и актуализира контекста едва след завършване. Подобни пакетни заявки съществуват за актуализиране (NSBatchUpdateRequest) и вмъкване (NSBatchInsertRequest).

Пример за CRUD операции

CRUD (Create, Read, Update, Delete) в Core Data се изпълнява чрез методи на контекста: insert, fetch, save и delete. Всички промени са временни до извикването на context.save() — методът запазва промените в постоянното SQLite хранилище. При грешка при запазване контекстът остава в променено състояние за повторен опит.

let context = container.viewContext

// Създаване
let user = User(context: context)
user.id = 42
user.name = "Alice"

// Четене
let request = User.fetchRequest()
request.predicate = NSPredicate(format: "name CONTAINS %@", "Ali")
request.sortDescriptors = [NSSortDescriptor(key: "name", ascending: true)]
let results = try context.fetch(request)

// Актуализиране
results.first?.name = "Alice Updated"

// Изтриване
if let first = results.first { context.delete(first) }

// Запазване
try context.save()

Запазване на контекста (context.save()) — критична операция. Ако запазването не бъде извикано, всички промени остават само в паметта. Контекстът проследява състоянието hasChanges, което може да се провери преди запазване. За фонови операции използвайте newBackgroundContext със собствено запазване, а за UI — viewContext с автоматично запазване по таймер или при преминаване на приложението на заден план.

Най-добри практики за Core Data

Първа практика — използвайте NSPersistentCloudKitContainer за синхронизация на данни между устройствата на потребителя чрез iCloud. Облачната синхронизация се активира чрез добавяне на CloudKit опция към описанието на хранилището. Core Data автоматично управлява конфликтите по време на синхронизация и обединява промени от други устройства.

Втора практика — избягвайте fetchRequest без предикат върху големи таблици. Всяко безусловно извличане зарежда всички обекти на обекта в паметта, което води до висока консумация на RAM и забавяне на UI. Винаги използвайте предикати и лимити. За пагинация приложете fetchLimit и fetchOffset в NSFetchRequest.

Трета практика — конфигурирайте mergePolicy за разрешаване на конфликти при многонишков достъп. NSMergeByPropertyObjectTrumpMergePolicy актуализира конфликтните свойства от последния запазен контекст. NSRollbackMergePolicy отменя промените на текущия контекст при конфликт. Изборът на политика зависи от бизнес логиката на приложението.

Четвърта практика — използвайте NSFetchedResultsController за интеграция с таблици и колекции. Той автоматично се абонира за известия NSManagedObjectContextDidSave, зарежда само необходимите обекти (faulting) и уведомява делегата за вмъквания, изтривания и премествания със съответните индексни пътища за анимация на UITableView.

Производителност: prefetching и faulting

Faulting — механизъм за мързеливо зареждане на Core Data обекти. Управляваният обект, върнат от fetch заявка, е в състояние fault — неговите атрибути не са напълно заредени, само идентификаторът. Пълното зареждане (fire fault) настъпва при първия достъп до който и да е атрибут. Relationship prefetching (setRelationshipKeyPathsForPrefetching) зарежда свързани обекти предварително, избягвайки N+1 заявки.

extension UserRepository {
    func fetchUsersWithPosts() throws -> [User] {
        let request = User.fetchRequest()
        request.predicate = NSPredicate(format: "isActive == YES")
        request.relationshipKeyPathsForPrefetching = ["posts"]
        request.returnsObjectsAsFaults = false
        request.fetchBatchSize = 20

        let context = container.viewContext
        return try context.fetch(request)
    }
}

fetchBatchSize = 20 принуждава Core Data да зарежда данни на порции от по 20 обекта (за показване на екрана), без да зарежда цялата таблица наведнъж. Флагът returnsObjectsAsFaults = false гарантира, че атрибутите на всички потребители са заредени незабавно, което е полезно при директно показване. Prefetching на връзката "posts" избягва отделни заявки за всеки потребител при достъп до публикации.