Core Data — kulcsfontosságú fogalmak, NSManagedObject és architektúra

Mi az a Core Data?

Core Data — objektumgráf-kezelő és adatmegőrzési keretrendszer, amely az Apple Cocoa Touch SDK része. Objektumorientált felületet biztosít az adatokkal való munkához: a fejlesztő entitásokkal (Entity), attribútumokkal és kapcsolatokkal (Relationship) dolgozik, a Core Data pedig ezeket az objektumokat relációs adatbázis rekordokká alakítja a motorháztető alatt.

A Core Data a Mac OS X 10.4 Tiger (2005) rendszerben jelent meg macOS-re, és az iOS 3.0 (2009) rendszerbe portolták. Több mint 20 év alatt a keretrendszer egy egyszerű SQLite feletti absztrakciós rétegből teljes veremmé fejlődött, amely támogatja a felhőszinkronizációt a NSPersistentCloudKitContainer segítségével, a többszálúságot automatikus kontextuskezeléssel és az aszinkron betöltést a Swift Concurrency-n keresztül.

A Slack Community (2025) iOS fejlesztők körében végzett felmérése szerint a Core Data a kereskedelmi iOS alkalmazások 68%-ában használatos helyi adattárolásra. Annak ellenére, hogy kritizálják a bonyolultsága és többrétegűsége miatt, a keretrendszer továbbra is szabvány marad az Apple alkalmazások számára a rendszerrel való szoros integrációnak, a nulla költségnek (beépítve az SDK-ba) és az iCloud szinkronizáció támogatásának köszönhetően.

A Core Data nem adatbázis

Gyakori tévhit — a Core Data-t adatbázisnak tekinteni. A keretrendszer nem hajt végre közvetlenül SQL lekérdezéseket, és nem DBMS. A Core Data egy objektumkezelő réteg (object graph management), amely SQLite-ot, Binary-t vagy In-Memory-t használhat az adatok megőrzésére. Analógia: a Core Data olyan, mint egy ORM (Hibernate vagy Entity Framework), de az Apple ökoszisztémához, az alatta lévő SQLite pedig olyan, mint a MySQL a Hibernate alatt.

Core Data architektúra: vermek és komponensek

A Core Data verem négy egymással összekapcsolt komponensből áll: NSManagedObjectModel (adatséma), NSPersistentStoreCoordinator (tároló-koordinátor), NSManagedObjectContext (munka kontextus) és NSPersistentContainer (egységes konténer, amely mindhármat egyesíti iOS 10-től). Az NSPersistentContainer automatizálja a verem létrehozását és konfigurálását.

Minden komponens szigorúan meghatározott funkciót tölt be. Az NSManagedObjectModel betölti a .xcdatamodeld fájlt az entitások leírásával. Az NSPersistentStoreCoordinator összekapcsolja a modellt a fizikai tárolófájllal (SQLite). Az NSManagedObjectContext ideiglenes területet biztosít az objektumokkal való munkához. A Container mindent egyetlen inicializálási hívásba egyesít.

Core Data tárolótípusok

SQLite (NSSQLiteStoreType) — a legtöbb alkalmazásban használt standard tároló. Az adatok egy .sqlite fájlban tárolódnak ACID tranzakciók támogatásával. Binary (NSBinaryStoreType) — bináris formátumú tároló kis adathalmazokhoz (néhány száz objektumig). In-Memory (NSInMemoryStoreType) — ideiglenes tároló a RAM-ban lemezre mentés nélkül, tesztekhez és gyorsítótárhoz használatos.

A tároló kiválasztása egyetlen sorral történik az NSPersistentStoreDescription inicializálásakor. A fejlesztő átválthatja a tárolót SQLite-ról In-Memory-ra (egységtesztekhez) vagy CloudKit-re (iCloud szinkronizációhoz) anélkül, hogy megváltoztatná az objektumokkal való munka kódját — a Core Data elvonatkoztatja a tárolótípusok közötti különbséget egy egységes kontextus API segítségével.

NSManagedObject és NSManagedObjectContext

NSManagedObject — az összes Core Data objektum alaposztálya, amely egy entitásrekordot képvisel. Minden felügyelt objektum rendelkezik egyedi NSManagedObjectID-vel (állandó azonosító), egy kontextushoz van kötve, és nyomon követi változásait KVO (Key-Value Observing) segítségével. A fejlesztő az NSManagedObject alosztályait hozza létre az entitás típusos tulajdonságainak meghatározásához.

NSManagedObjectContext — a Core Data központi komponense, amely munkaterületet biztosít az összes objektumművelethez. A kontextus nyomon követi az objektumok hozzáadását, törlését és módosítását (change tracking), támogatja a műveletek visszavonását az undoManager segítségével, és automatikusan egyesíti a más kontextusokból származó változásokat mentési értesítések fogadásakor.

Kontextusok szálbiztonsága

A privát sorok szabálya: Az NSManagedObjectContext .privateQueueConcurrencyType vagy .mainQueueConcurrencyType típussal jön létre. A fő kontextus a fő UI szálhoz van kötve, a privát kontextusok háttérsorokon futnak. Minden kontextus csak a saját sorában használható — egy felügyelt objektum elérése másik szálból crash-t okoz. A parentContext lehetővé teszi a kontextusok hierarchiájának megszervezését aszinkron íráshoz.

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
    }
}

Az NSPersistentContainer automatikusan létrehozza a viewContext-ot (main queue), és newBackgroundContext()-et biztosít háttérműveletekhez. A automaticallyMergesChangesFromParent = true tulajdonság hatására a viewContext automatikusan átveszi a változásokat a háttérkontextusokból azok mentésekor, frissítve a UI-t anélkül, hogy manuálisan újra kellene kérdezni az adatokat.

Persistent Store és kapcsolat az SQLite-tal

NSPersistentStoreCoordinator kezeli a fizikai adattárolást: megnyitja a fájlt, létrehozza az SQLite táblákat a modell alapján, migrációkat hajt végre séma változásakor. Az NSSQLiteStoreType típusú NSPersistentStoreDescription inicializálásakor a Core Data létrehoz egy SQLite fájlt a .xcdatamodeld modellnek megfelelő sémával.

A Core Data nem használ standard SQL lekérdezéseket SELECT/INSERT/UPDATE segítségével. Ehelyett belső SQL parancsokat generál a modell és a NSFetchRequest-en keresztüli lekérdezések alapján. A fejlesztő bekapcsolhatja az SQL naplózást a -com.apple.CoreData.SQLDebug 1 indítási argumentummal a lekérdezési teljesítmény hibakereséséhez.

Core Data migrációk

Könnyű migráció (Lightweight Migration) — az SQLite séma automatikus frissítési folyamata új attribútumok hozzáadásakor, optional/required módosításakor vagy renamingID segítségével történő átnevezésekor. Nehéz migrációra van szükség a séma gyökeres változásai esetén, mint az entitások összevonása vagy felosztása, és egyéni NSMigrationManager segítségével hajtható végre.

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)") }
}

Az automatikus migráció beállítása az NSMigratePersistentStoresAutomaticallyOption és NSInferMappingModelAutomaticallyOption segítségével lehetővé teszi a Core Data számára, hogy önállóan frissítse az SQLite fájlt attribútumok vagy entitások hozzáadásakor a modell új verziójában. Ha a migráció nem lehetséges, a store coordinator hibát dob az ok leírásával — a fejlesztőnek egyéni migrációt kell megvalósítania az NSMigrationManager segítségével.

Core Data a gyakorlatban: kód és példák

NSFetchRequest — a fő eszköz objektumok lekéréséhez a Core Data-ból. A lekérdezés tartalmazza az entitás nevét, predikátumot (szűrő), rendezéseket, limitet és offsetet. Az eredmény NSManagedObject vagy típusos alosztályok tömbjeként kerül visszaadásra. Az NSPredicate támogatja az összetett feltételeket AND, OR, IN, LIKE és allekérdezések segítségével.

NSBatchDeleteRequest — hatékony módja objektumok tömeges törlésének anélkül, hogy mindegyiket a memóriába töltené. A lekérdezés SQLite szinten hajtódik végre, megkerülve a managed object context-et, és csak befejezés után frissíti a kontextust. Hasonló batch lekérdezések léteznek frissítéshez (NSBatchUpdateRequest) és beszúráshoz (NSBatchInsertRequest).

CRUD műveletek példája

CRUD (Create, Read, Update, Delete) a Core Data-ban a kontextus metódusain keresztül történik: insert, fetch, save és delete. Minden változás ideiglenes a context.save() hívásáig — a metódus elmenti a változásokat az állandó SQLite tárolóba. Mentési hiba esetén a kontextus módosított állapotban marad az újrapróbálkozáshoz.

let context = container.viewContext

// Létrehozás
let user = User(context: context)
user.id = 42
user.name = "Alice"

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

// Frissítés
results.first?.name = "Alice Updated"

// Törlés
if let first = results.first { context.delete(first) }

// Mentés
try context.save()

A kontextus mentése (context.save()) — kritikus művelet. Ha a mentés nem kerül meghívásra, minden változás csak a memóriában marad. A kontextus nyomon követi a hasChanges állapotot, amely mentés előtt ellenőrizhető. Háttérműveletekhez használja a newBackgroundContext-et saját mentéssel, a UI-hoz pedig a viewContext-ot automatikus mentéssel időzítő alapján vagy amikor az alkalmazás háttérbe kerül.

Core Data legjobb gyakorlatok

Első gyakorlat — használja az NSPersistentCloudKitContainer-t az adatok iCloudon keresztüli szinkronizálásához a felhasználó eszközei között. A felhőszinkronizáció a CloudKit opció hozzáadásával aktiválható a tároló leírásához. A Core Data automatikusan kezeli a konfliktusokat a szinkronizáció során, és egyesíti a más eszközökről érkező változásokat.

Második gyakorlat — kerülje a predikátum nélküli fetchRequest-et nagy táblákon. Minden feltétel nélküli lekérés betölti az entitás összes objektumát a memóriába, ami magas RAM-fogyasztáshoz és a UI lelassulásához vezet. Mindig használjon predikátumokat és limiteket. Lapozáshoz használja a fetchLimit és fetchOffset paramétereket az NSFetchRequest-ben.

Harmadik gyakorlat — konfigurálja a mergePolicy-t a konfliktusok feloldásához többszálú hozzáférés esetén. Az NSMergeByPropertyObjectTrumpMergePolicy frissíti a konfliktusos tulajdonságokat az utoljára mentett kontextusból. Az NSRollbackMergePolicy visszavonja az aktuális kontextus változásait konfliktus esetén. A házirend kiválasztása az alkalmazás üzleti logikájától függ.

Negyedik gyakorlat — használja az NSFetchedResultsController-t a táblákkal és gyűjteményekkel való integrációhoz. Automatikusan feliratkozik az NSManagedObjectContextDidSave értesítésekre, csak a szükséges objektumokat tölti be (faulting), és értesíti a delegáltat a beszúrásokról, törlésekről és áthelyezésekről a megfelelő index elérési utakkal az UITableView animációhoz.

Teljesítmény: prefetching és faulting

Faulting — a Core Data objektumok lusta betöltési mechanizmusa. A fetch lekérdezés által visszaadott managed object fault állapotban van — attribútumai nincsenek teljesen betöltve, csak az azonosító. A teljes betöltés (fire fault) az első attribútum eléréskor történik. Relationship prefetching (setRelationshipKeyPathsForPrefetching) előre betölti a kapcsolódó objektumokat, elkerülve az N+1 lekérdezéseket.

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 arra kényszeríti a Core Data-t, hogy az adatokat 20 objektumos adagokban töltse be (a képernyőn való megjelenítéshez), anélkül hogy egyszerre betöltené a teljes táblát. A returnsObjectsAsFaults = false jelző garantálja, hogy az összes felhasználó attribútumai azonnal betöltődnek, ami hasznos a közvetlen megjelenítésnél. A "posts" kapcsolat prefetching-je elkerüli a külön lekérdezéseket minden felhasználóhoz a bejegyzések elérésekor.