Core Data — mga pangunahing konsepto, NSManagedObject at arkitektura

Ano ang Core Data?

Core Data — ay isang framework para sa pamamahala ng graph ng bagay at persistency, bahagi ng Cocoa Touch SDK ng Apple. Nagbibigay ito ng object-oriented na interface para sa pagtatrabaho sa data: ang developer ay nag-o-operate sa mga entity (Entity), attribute, at relasyon (Relationship), at ang Core Data ay nagko-convert ng mga bagay na ito sa mga talaan ng relational database sa ilalim ng hood.

Ang Core Data ay ipinakilala sa Mac OS X 10.4 Tiger (2005) para sa macOS at na-port sa iOS 3.0 (2009). Sa loob ng mahigit 20 taon, ang framework ay umunlad mula sa isang simpleng abstraction layer sa itaas ng SQLite patungo sa isang kumpletong stack na may suporta para sa cloud synchronization sa pamamagitan ng NSPersistentCloudKitContainer, multithreading sa pamamagitan ng awtomatikong pamamahala ng konteksto, at asynchronous na pag-load sa pamamagitan ng Swift Concurrency.

Ayon sa survey ng mga iOS developer mula sa Slack Community (2025), ang Core Data ay ginagamit sa 68% ng mga komersyal na iOS application para sa lokal na imbakan ng data. Sa kabila ng pagiging kritikal dahil sa pagiging kumplikado at multi-layered, ang framework ay nananatiling pamantayan para sa mga Apple application dahil sa malapit na pagsasama sa system, zero na gastos (naka-embed sa SDK), at suporta para sa iCloud synchronization.

Ang Core Data ay hindi isang database

Isang karaniwang maling paniniwala — ang ituring ang Core Data bilang isang database. Ang framework ay hindi direktang nagpapatupad ng mga SQL query at hindi isang DBMS. Ang Core Data ay isang layer ng pamamahala ng bagay (object graph management) na maaaring gumamit ng SQLite, Binary, o In-Memory para sa persistency. Analohiya: Ang Core Data ay parang ORM tulad ng Hibernate o Entity Framework, ngunit para sa Apple ecosystem, at ang SQLite sa ilalim nito — tulad ng MySQL sa ilalim ng Hibernate.

Arkitektura ng Core Data: mga stack at component

Ang Core Data stack ay binubuo ng apat na magkakaugnay na component: NSManagedObjectModel (schema ng data), NSPersistentStoreCoordinator (coordinator ng imbakan), NSManagedObjectContext (konteksto ng trabaho), at NSPersistentContainer (nag-iisang container na pinagsasama ang tatlo mula noong iOS 10). Ang NSPersistentContainer ay nag-automate ng paglikha at pagsasaayos ng stack.

Ang bawat component ay gumaganap ng isang mahigpit na tinukoy na function. NSManagedObjectModel ay naglo-load ng .xcdatamodeld file na may deskripsyon ng mga entity. Ang NSPersistentStoreCoordinator ay nag-uugnay ng modelo sa pisikal na file ng imbakan (SQLite). Ang NSManagedObjectContext ay nagbibigay ng pansamantalang lugar para sa pagtatrabaho sa mga bagay. Pinagsasama ng Container ang lahat sa isang tawag sa pagsisimula.

Mga uri ng imbakan ng Core Data

SQLite (NSSQLiteStoreType) — ang karaniwang imbakan na ginagamit sa karamihan ng mga application. Ang data ay nai-save sa isang .sqlite file na may suporta para sa ACID transaction. Binary (NSBinaryStoreType) — imbakan sa binary format para sa maliliit na set ng data (hanggang ilang daang bagay). In-Memory (NSInMemoryStoreType) — pansamantalang imbakan sa RAM na walang pag-save sa disk, ginagamit para sa pagsubok at cache.

Ang pagpili ng imbakan ay itinatakda ng isang linya sa pagsisimula ng NSPersistentStoreDescription. Ang developer ay maaaring lumipat ng imbakan mula SQLite patungong In-Memory para sa unit test o sa CloudKit para sa iCloud synchronization nang hindi binabago ang code para sa pagtatrabaho sa mga bagay — ang Core Data ay nag-a-abstrak ng pagkakaiba sa pagitan ng mga uri ng imbakan gamit ang isang pare-parehong API ng konteksto.

NSManagedObject at NSManagedObjectContext

NSManagedObject — ang base class para sa lahat ng Core Data object na kumakatawan sa isang talaan ng entity. Ang bawat managed object ay may natatanging NSManagedObjectID (permanenteng identifier), nakatali sa isang konteksto, at sinusubaybayan ang mga pagbabago nito sa pamamagitan ng KVO (Key-Value Observing). Ang developer ay gumagawa ng mga subclass ng NSManagedObject para tukuyin ang mga naka-type na property ng entity.

NSManagedObjectContext — ang pangunahing component ng Core Data na nagbibigay ng workspace para sa lahat ng operasyon sa mga bagay. Sinusubaybayan ng konteksto ang mga pagdaragdag, pagtanggal, at pagbabago ng mga bagay (change tracking), sumusuporta sa pag-undo ng mga operasyon sa pamamagitan ng undoManager, at awtomatikong pinagsasama ang mga pagbabago mula sa iba pang mga konteksto kapag nakatanggap ng mga notification sa pag-save.

Kaligtasan ng thread ng mga konteksto

Patakaran ng pribadong queue: Ang NSManagedObjectContext ay ginagawa na may uri na .privateQueueConcurrencyType o .mainQueueConcurrencyType. Ang main context ay nakatali sa pangunahing UI thread, ang mga pribadong konteksto ay tumatakbo sa mga background queue. Ang bawat konteksto ay dapat gamitin lamang sa sarili nitong queue — ang pag-access sa managed object mula sa ibang thread ay nagdudulot ng crash. Ang parentContext ay nagpapahintulot sa pag-oorganisa ng hierarchy ng mga konteksto para sa asynchronous na pagsulat.

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 ay awtomatikong gumagawa ng viewContext (main queue) at nagbibigay ng newBackgroundContext() para sa mga background operation. Ang property na automaticallyMergesChangesFromParent = true ay nagiging sanhi ng viewContext na awtomatikong kumuha ng mga pagbabago mula sa mga background context kapag nai-save ang mga ito, ina-update ang UI nang walang manu-manong muling pagkuha ng data.

Persistent Store at relasyon sa SQLite

NSPersistentStoreCoordinator ay namamahala ng pisikal na imbakan ng data: nagbubukas ng file, gumagawa ng mga SQLite table batay sa modelo, nagpapatupad ng mga migration kapag nagbago ang schema. Sa pagsisimula ng NSPersistentStoreDescription na may uri na NSSQLiteStoreType, ang Core Data ay gumagawa ng SQLite file na may schema na tumutugma sa .xcdatamodeld na modelo.

Ang Core Data ay hindi gumagamit ng karaniwang SQL query sa pamamagitan ng SELECT/INSERT/UPDATE. Sa halip, ito ay bumubuo ng mga panloob na SQL command batay sa modelo at mga query sa pamamagitan ng NSFetchRequest. Ang developer ay maaaring mag-enable ng SQL logging sa pamamagitan ng startup argument -com.apple.CoreData.SQLDebug 1 para sa pag-debug ng performance ng query.

Mga migration ng Core Data

Lightweight Migration — ang awtomatikong proseso ng pag-update ng SQLite schema kapag nagdaragdag ng mga bagong attribute, nagbabago ng optional/required, o nagpapalit ng pangalan gamit ang renamingID. Ang mabigat na migration ay kinakailangan para sa malalaking pagbabago sa schema tulad ng pagsasama o paghahati ng mga entity, at ginagawa sa pamamagitan ng custom na 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)") }
}

Ang pagsasaayos ng awtomatikong migration sa pamamagitan ng NSMigratePersistentStoresAutomaticallyOption at NSInferMappingModelAutomaticallyOption ay nagpapahintulot sa Core Data na malayang i-update ang SQLite file kapag nagdaragdag ng mga attribute o entity sa bagong bersyon ng modelo. Kung hindi posible ang migration, ang store coordinator ay nagtataas ng error na may deskripsyon ng dahilan — ang developer ay dapat magpatupad ng custom na migration sa pamamagitan ng NSMigrationManager.

Core Data sa praktika: code at mga halimbawa

NSFetchRequest — ang pangunahing tool para sa pagkuha ng mga bagay mula sa Core Data. Ang query ay naglalaman ng pangalan ng entity, predicate (filter), sorting, limit, at offset. Ang resulta ay ibinabalik bilang array ng NSManagedObject o naka-type na subclass. Ang NSPredicate ay sumusuporta sa mga kumplikadong kondisyon na may AND, OR, IN, LIKE, at subquery.

NSBatchDeleteRequest — isang mahusay na paraan para sa maramihang pagtanggal ng mga bagay nang hindi nilo-load ang bawat isa sa memorya. Ang query ay isinasagawa sa antas ng SQLite, na lumalampas sa managed object context, at ina-update lamang ang konteksto pagkatapos makumpleto. Ang mga katulad na batch query ay umiiral para sa pag-update (NSBatchUpdateRequest) at pagpasok (NSBatchInsertRequest).

Halimbawa ng CRUD operations

CRUD (Create, Read, Update, Delete) sa Core Data ay isinasagawa sa pamamagitan ng mga pamamaraan ng konteksto: insert, fetch, save, at delete. Lahat ng pagbabago ay pansamantala hanggang sa tawag ng context.save() — ang pamamaraan ay nagse-save ng mga pagbabago sa permanenteng SQLite storage. Sa error ng pag-save, ang konteksto ay nananatili sa binagong estado para sa muling pagsubok.

let context = container.viewContext

// Gumawa
let user = User(context: context)
user.id = 42
user.name = "Alice"

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

// I-update
results.first?.name = "Alice Updated"

// Tanggalin
if let first = results.first { context.delete(first) }

// I-save
try context.save()

Pag-save ng konteksto (context.save()) — isang kritikal na operasyon. Kung hindi tinawag ang pag-save, lahat ng pagbabago ay mananatili lamang sa memorya. Sinusubaybayan ng konteksto ang estado ng hasChanges, na maaaring suriin bago mag-save. Para sa mga background operation, gamitin ang newBackgroundContext na may sariling pag-save, at para sa UI — viewContext na may awtomatikong pag-save batay sa timer o kapag ang app ay pumunta sa background.

Mga pinakamahusay na kasanayan sa Core Data

Unang kasanayan — gamitin ang NSPersistentCloudKitContainer para sa synchronization ng data sa pagitan ng mga device ng user sa pamamagitan ng iCloud. Ang cloud synchronization ay pinagana sa pamamagitan ng pagdaragdag ng CloudKit option sa paglalarawan ng imbakan. Ang Core Data ay awtomatikong namamahala ng mga conflict sa panahon ng synchronization at pinagsasama ang mga pagbabago mula sa iba pang mga device.

Pangalawang kasanayan — iwasan ang fetchRequest na walang predicate sa malalaking table. Ang bawat walang kondisyong pagkuha ay naglo-load ng lahat ng object ng entity sa memorya, na humahantong sa mataas na konsumo ng RAM at pagbagal ng UI. Laging gumamit ng mga predicate at limit. Para sa pagination, gamitin ang fetchLimit at fetchOffset sa NSFetchRequest.

Pangatlong kasanayan — i-configure ang mergePolicy para sa paglutas ng mga conflict sa multi-thread access. Ang NSMergeByPropertyObjectTrumpMergePolicy ay nag-u-update ng mga conflict na property mula sa huling na-save na konteksto. Ang NSRollbackMergePolicy ay nagba-balik ng mga pagbabago ng kasalukuyang konteksto sa conflict. Ang pagpili ng patakaran ay depende sa business logic ng application.

Pang-apat na kasanayan — gamitin ang NSFetchedResultsController para sa pagsasama sa mga table at collection. Ito ay awtomatikong nag-subscribe sa mga notification ng NSManagedObjectContextDidSave, naglo-load lamang ng mga kinakailangang bagay (faulting), at nagpapaalam sa delegate tungkol sa mga pagpasok, pagtanggal, at paglipat na may kaukulang index path para sa UITableView animation.

Performance: prefetching at faulting

Faulting — ang mekanismo ng tamad na pag-load ng Core Data object. Ang managed object na ibinalik ng fetch query ay nasa fault state — ang mga attribute nito ay hindi ganap na na-load, tanging ang identifier. Ang buong pag-load (fire fault) ay nangyayari sa unang pag-access sa anumang attribute. Relationship prefetching (setRelationshipKeyPathsForPrefetching) ay naglo-load ng mga kaugnay na bagay nang maaga, iniiwasan ang N+1 query.

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 ay pinipilit ang Core Data na mag-load ng data sa mga piraso ng 20 bagay (para sa pagpapakita sa screen), nang hindi nilo-load ang buong table nang sabay-sabay. Ang flag na returnsObjectsAsFaults = false ay ginagarantiyahan na ang mga attribute ng lahat ng user ay agad na na-load, na kapaki-pakinabang para sa direktang pagpapakita. Ang prefetching ng relasyon na "posts" ay umiiwas sa hiwalay na query para sa bawat user kapag nag-a-access ng mga post.