Core Data — ano ito, modelo ng data at kung paano ito gumagana

Ano ang Core Data at ang papel nito sa iOS

Core Data — ay isang framework para sa pamamahala ng object graph at persistensya, bahagi ng Cocoa Touch. Taliwas sa karaniwang maling paniniwala, ang Core Data ay hindi isang database, kundi isang layer ng pamamahala ng object na maaaring gumamit ng SQLite bilang isa sa mga imbakan. Ang pangunahing gawain ng Core Data ay subaybayan ang mga pagbabago sa object, pamahalaan ang kanilang lifecycle at i-sync ang estado sa disk.

Ang framework ay nagbibigay ng object graph, kung saan ang bawat Managed Object ay sinusubaybayan ng konteksto para sa mga pagbabago. Kapag na-save ang konteksto, lahat ng binago, idinagdag at tinanggal na object ay kinukumpirma sa permanenteng imbakan sa isang transaksyon. Ito ay nagpapalaya sa developer mula sa pagsulat ng mga SQL query at manu-manong pamamahala ng mga transaksyon.

Ayon sa mga statistika ng Swift Developer Survey (2025), ang Core Data ay ginagamit sa 52% ng mga iOS application na gumagawa gamit ang lokal na data. Sa kabila ng paglitaw ng mga modernong alternatibo (SwiftData, Realm), ang Core Data ay nananatiling pangunahing framework sa mga umiiral na proyekto ng Apple dahil sa kapanahunan at malalim na pagsasama sa system.

Gamitin ang Core Data para sa mga proyektong may modelo ng data na katamtaman ang pagiging kumplikado kung saan kailangan ang mga relasyon sa pagitan ng object, pag-undo ng mga pagbabago at awtomatikong caching sa pamamagitan ng faulting mechanism.

Ang arkitektura ng Core Data ay binuo sa paligid ng konsepto ng Managed Object Context — isang workspace na sumusubaybay sa lahat ng pagbabago ng object. Ang konteksto ay sumusuporta sa pag-undo (undo/redo) sa pamamagitan ng built-in na NSUndoManager, na nagpapahintulot sa pagpapatupad ng mga draft at pagkansela ng mga aksyon nang walang manu-manong pag-save ng mga snapshot ng estado. Kapag tinawag ang save(), kinukumpirma ng konteksto ang lahat ng pagbabago sa isang transaksyon sa permanenteng imbakan, na ginagarantiya ang atomicity at consistency ng data.

Modelo ng data: Entity, Attributes, Relationships

Ang modelo ng data ng Core Data ay tinukoy sa file na .xcdatamodeld — ang visual editor ng Xcode, kung saan inilalarawan ang lahat ng Entity, ang kanilang mga attribute at relasyon. Sa compilation, ang modelo ay nise-serialize sa .momd at nilo-load sa pamamagitan ng NSManagedObjectModel.

Entity at Attributes

Entity — ay isang paglalarawan ng uri ng data, kahalintulad ng isang table sa SQL. Ang bawat Entity ay naglalaman ng isang set ng Attributes — may pangalan na field na may uri ng data (String, Integer, Date, Boolean, Data). Hindi tulad ng Room, ang Core Data ay nangangailangan ng tahasang pagpili ng uri para sa bawat attribute sa pamamagitan ng editor ng modelo.

Relationships

Relationship — relasyon sa pagitan ng Entity, kahalintulad ng foreign key sa SQL. Sinusuportahan ng Core Data ang lahat ng uri ng relasyon: isa-sa-isa, isa-sa-marami at marami-sa-marami. Para sa bawat relasyon, naka-configure ang Delete Rule (Cascade, Nullify, Deny) — ang pag-uugali kapag tinatanggal ang nauugnay na object.

Ang pagpili ng Delete Rule ay kritikal para sa integridad ng data: ang Cascade nang walang pagsusuri ay maaaring magtanggal ng isang katlo ng database, at ang Deny ay maaaring mag-block ng operasyon na may hindi maintindihang error. Sa production code, inirerekomenda ang Nullify na may manu-manong pagproseso ng mga orphan record.

Sa editor ng modelo ng Xcode, ang developer ay maaaring magtakda hindi lamang ng Entity at attribute, kundi pati na rin ng constraints (mga limitasyon sa pagiging natatangi), index para sa pagpapabilis ng mga query at default values para sa mga attribute. Lahat ng pagbabago sa modelo ay nami-compile sa .momd file, na nilo-load sa pagsisimula ng NSPersistentContainer. Ang pag-version ng modelo (Model Versioning) ay nagpapahintulot sa pagpapanatili ng maraming bersyon ng schema at pagsasagawa ng migrasyon sa pagitan ng mga ito.

Stack ng Core Data: PersistentContainer at Context

NSPersistentContainer — isang pinag-isang object na namamahala sa stack ng Core Data mula noong iOS 10 at macOS 10.12. Ini-encapsulate nito ang NSManagedObjectModel, NSPersistentStoreCoordinator at NSManagedObjectContext, na nag-automate ng pag-load ng modelo at configuration ng imbakan. Para sa mas lumang bersyon, ang stack ay binuo nang manu-mano, ngunit ngayon ito ay hindi inirerekomenda.

let container = NSPersistentContainer(name: "DataModel")
container.loadPersistentStores { _, error in
    if let error { fatalError("Core Data load failed: \(error)") }
}
let context = container.viewContext

viewContext — ang pangunahing konteksto na naka-link sa pangunahing thread. Lahat ng pagbasa at pag-update ng UI ay ginagawa sa pamamagitan nito. Ang pagsulat ng data para sa pagganap ay inirerekomenda na gawin sa isang child context na may pribadong queue at kasunod na pag-sync.

NSPersistentStoreCoordinator

Ang coordinator na NSPersistentStoreCoordinator ay nag-uugnay sa modelo sa pisikal na imbakan sa disk. Sinusuportahan ng Core Data ang maraming uri ng imbakan: SQLite (inirerekomenda), Binary at In-Memory. Ang imbakan ng SQLite ay sumusuporta sa migrasyon, incremental backup at pagiging matatag sa mga pagkabigo sa proseso ng pagsulat.

NSFetchRequest at pagtatrabaho sa data

NSFetchRequest — isang object na naglalarawan ng query sa imbakan ng Core Data. Naglalaman ito ng pangalan ng Entity, predicate ng pag-filter, pag-uuri at mga setting ng pagkuha. Ang query ay isinasagawa sa pamamagitan ng context.fetch(), na nagbabalik ng array ng NSManagedObject.

let request = NSFetchRequest<User>(entityName: "User")
request.predicate = NSPredicate(format: "age >= %d", 18)
request.sortDescriptors = [NSSortDescriptor(key: "name", ascending: true)]
request.fetchLimit = 50

let results = try context.fetch(request)

Sinusuportahan ng NSPredicate ang mga kumplikadong kondisyon: LIKE, IN, BETWEEN, CONTAINS[c] (case-insensitive), SUBQUERY para sa nested query sa mga nauugnay na Entity. Sinusuportahan din ng Core Data ang NSFetchedResultsController — isang klase para sa reactive na pag-load ng data sa UITableView, na awtomatikong sumusubaybay sa mga pagbabago at nag-a-update ng table na may mga animated na seksyon.

Core Data sa multi-thread na kapaligiran

Ang pagtatrabaho sa Core Data sa isang multi-thread na application ay nangangailangan ng mahigpit na pagsunod sa mga patakaran: ang NSManagedObject ay hindi maaaring direktang ipasa sa pagitan ng mga thread. Ang bawat thread (o queue) ay dapat gumamit ng sarili nitong konteksto. Ang pangunahing approach — paggawa ng child NSManagedObjectContext na may pribadong queue (NSPrivateQueueConcurrencyType) para sa pagsulat at viewContext para sa pagbasa.

Ang child context ay nase-save sa parent, at pagkatapos ang parent — sa imbakan sa disk. Ito ay ginagarantiya na ang mga pagbabago ay hindi humaharang sa pangunahing thread at ang UI ay palaging nakakakita ng pare-parehong estado sa pamamagitan ng mergeChanges o awtomatikong pag-update ng viewContext kapag nag-save.

Ang Core Data ay gumagamit ng faulting — isang mekanismo ng deferred loading ng mga nauugnay na object. Kapag kumukuha ng User nang hindi hinihiling ang kanyang mga addresses, ang mga nauugnay na Address ay hindi nilo-load hangga't hindi sila naa-access sa pamamagitan ng dot notation. Ang faulting ay nakakatipid ng memory at nagpapabilis ng pag-load, ngunit maaaring magdulot ng hindi inaasahang pag-access sa disk sa pangunahing thread kung ang access ay hindi kontrolado sa mga background context.

Para sa mahusay na multi-threading, gamitin ang NSBatchInsertRequest at NSBatchDeleteRequest para sa mass insertion at deletion nang hindi nilo-load ang mga object sa memory — ito ay kritikal para sa pag-sync ng data sa server.

Ang mga batch operation ay direktang isinasagawa sa antas ng NSPersistentStoreCoordinator, na lumalampas sa konteksto at object graph. Ito ay nagpapahintulot na magpasok ng 10,000 record sa ilang millisecond nang hindi lumilikha ng 10,000 NSManagedObject instance sa memory. Pagkatapos isagawa ang batch query, ang konteksto ay dapat i-update sa pamamagitan ng mergeChangesFromContextDidSaveNotification upang maipakita ng UI ang bagong data. Inirerekomenda ng Apple ang mga batch operation para sa paunang pag-load ng data at gabi-gabing pag-sync sa server.

Para sa pagsubaybay sa mga pagbabago sa Core Data, ginagamit ang NSPersistentHistoryTracking — isang mekanismo na nagtatala ng bawat transaksyon (insertion, update, deletion) sa isang hiwalay na kasaysayan. Ang pag-activate ng history tracking ay nagpapahintulot sa pag-sync ng data sa pagitan ng iba't ibang proseso at application na gumagawa sa parehong SQLite file, halimbawa sa pagitan ng pangunahing application at Notification Service Extension. Ang pag-activate ay ginagawa sa pamamagitan ng NSPersistentStoreDescription na may flag na persistentHistoryTrackingKey, at pagbasa sa pamamagitan ng NSPersistentHistoryChangeRequest na may filter batay sa petsa at uri ng transaksyon.

Para sa debugging at profiling ng performance ng Core Data, ginagamit ang tool na Core Data Profiler mula sa suite na Instruments sa Xcode sa macOS. Ipinapakita nito ang lahat ng operasyon ng pagkuha, pagpasok, pagtanggal at pag-save na may tagal ng bawat operasyon at bilang ng mga load na object sa mga table at timeline graph. Ang developer ay maaaring makilala ang mga problemang lugar: maraming pagkuha ng parehong query (kakulangan ng caching), pagtagas ng fault object habang nag-scroll ng table o pag-block ng pangunahing thread dahil sa synchronous loading ng mga kaugnay na entity. Inirerekomenda ang profiling sa isang tunay na device, hindi sa simulator, dahil ang performance ng simulator ay hindi sumasalamin sa tunay na pag-uugali ng application sa iPhone o iPad.