En introduktion till Core Data

Om du läser detta antar jag att du är nybörjare på Core Data. Du kanske har hört talas om Core Data och vill ta reda på om det passar dig eller det projekt du arbetar med. Om den här beskrivningen stämmer in på dig, ta då plats. Den här Core Data-handledningen lär dig allt du behöver veta för att bättre förstå vad Core Data är och inte är.

Vad är Core Data

Utvecklare som är nya i ramverket tar sig väldigt ofta inte tid att lära sig vad Core Data är. Att inte veta vad Core Data är gör det mycket svårt att förstå vad det innebär. Jag vill ägna några minuter åt att utforska Core Datas natur och, ännu viktigare, klargöra vad Core Data är och inte är.

Vad är dess ursprung

Core Data är ett ramverk som utvecklats och underhålls av Apple. Det har funnits i mer än ett decennium och det gjorde sitt första intåg i macOS i samband med lanseringen av macOS Tiger 2005. År 2009 gjorde företaget ramverket tillgängligt för iOS med lanseringen av iOS 3.

Hur passar det in

Core Data är M:et i MVC, modellskiktet i din applikation. Även om Core Data kan lagra data på disk är datalagring faktiskt en valfri funktion i ramverket. Core Data är först och främst ett ramverk för att hantera en objektgraf.

Du har antagligen hört och läst om Core Data innan du gick den här kursen. Det betyder att du kanske redan vet att Core Data inte är en databas och att den hanterar din applikations objektgraf. Båda påståendena är sanna. Men vad betyder de egentligen?

Hantering av en objektgraf

Core Data hanterar först och främst en objektgraf. En objektgraf är inget annat än en samling objekt som är anslutna till varandra. Core Data-ramverket utmärker sig för att hantera komplexa objektgrafer.

Det tar hand om hanteringen av livscykeln för objekten i objektgrafen och det kan eventuellt persistera objektgrafen till disk. Den erbjuder också ett kraftfullt gränssnitt för att söka i den objektgraf som den hanterar.

Men Core Data är mycket mer än så. Ramverket lägger till ett antal andra övertygande funktioner, t.ex. inmatningsvalidering, versionering av datamodeller och ändringsspårning.

När du ska använda Core Data

Ramverket passar perfekt för ett stort antal program, men det är inte alla program som bör använda Core Data. Applikationer som behöver ett lättviktigt modellskikt bör inte använda Core Data. Det finns många lättviktsbibliotek som tillhandahåller denna typ av funktionalitet.

Om du letar efter en SQLite-wrapper är Core Data inte heller vad du behöver. Om du vill ha en lättviktig SQLite-wrapper med hög prestanda kan jag varmt rekommendera Gus Muellers FMDB. Detta robusta, mogna bibliotek tillhandahåller ett objektorienterat gränssnitt för att interagera med SQLite.

Core Data är ett utmärkt val om du vill ha en lösning som hanterar modellskiktet i din applikation.

Hur skiljer det sig från SQLite

Utvecklare som är nya för Core Data är ofta förvirrade över skillnaderna mellan SQLite och Core Data. Om du undrar om du behöver SQLite eller Core Data ställer du fel fråga. Kom ihåg att Core Data inte är en databas.

SQLite

SQLite är en lättviktsdatabas som har mycket hög prestanda och därför passar bra för mobila applikationer. Även om SQLite marknadsförs som en relationsdatabas är det viktigt att inse att det är du som utvecklare som ansvarar för att upprätthålla relationerna mellan de poster som lagras i databasen.

Core Data

Core Data går mycket längre. Den tillhandahåller en abstraktion som gör att du kan interagera med modellskiktet på ett objektorienterat sätt. Varje post som du interagerar med är ett objekt. Core Data ansvarar för objektgrafens integritet. Den ser till att objektgrafen hålls uppdaterad.

Core Data Begränsningar

Även om Core Data är ett fantastiskt ramverk finns det flera nackdelar. Dessa nackdelar är direkt relaterade till ramverkets natur och hur det fungerar.

Core Data kan bara utföra sin magi eftersom det håller objektgrafen som det hanterar i minnet. Detta innebär att den bara kan arbeta med poster när de befinner sig i minnet. Detta skiljer sig mycket från att utföra en SQL-fråga på en databas. Om du vill ta bort tusentals poster måste Core Data först ladda varje post i minnet. Det säger sig självt att detta leder till minnes- och prestandaproblem om det görs på fel sätt.

En annan viktig begränsning är Core Datas trådmodell. Ramverket förväntar sig att köras på en enda tråd. Lyckligtvis har Core Data utvecklats dramatiskt under årens lopp och ramverket har infört olika lösningar som gör det säkrare och enklare att arbeta med Core Data i en miljö med flera trådar.

För program som behöver hantera en komplex objektgraf är Core Data en utmärkt lösning. Om du bara behöver lagra en handfull orelaterade objekt är det kanske bättre med en lättviktslösning eller systemet med användarens standardinställningar.

Exploatering av Core Data-stacken

När du nu vet vad Core Data är och vad det inte är är det dags att zooma in på ramverkets byggstenar. Det är viktigt att du förstår hur de olika klasserna som gör att ramverket fungerar tillsammans.

Ramverkets stjärnor är:

• den hanterade objektmodellen
• den hanterade objektkontexten
• och koordinatorn för det persistenta lagret

Detta diagram visar hur dessa klasser förhåller sig till varandra. Låt oss börja med managed object model.

Managed Object Model

Den managed object model är en instans av klassen NSManagedObjectModel. Även om en typisk Core Data-applikation har en instans av NSManagedObjectModel-klassen är det möjligt att ha flera. Instansen för den hanterade objektmodellen representerar datamodellen för Core Data-applikationen.

Det ovanstående diagrammet visar att den hanterade objektmodellen är kopplad till datamodellen. Datamodellen representeras av en fil i applikationspaketet som innehåller applikationens dataskema. Dataskemat är inget annat än en samling enheter.

En enhet kan ha attribut och relationer som utgör applikationens datamodell. Kom ihåg för tillfället att den hanterade objektmodellen en instans är av klassen NSManagedObjectModel och att den datamodellen för Core Data-applikationen representerar.

Managed Object Context

En managed object context representeras av en instans av klassen NSManagedObjectContext. En Core Data-applikation har en eller flera hanterade objektkontexter som var och en hanterar en samling modellobjekt, instanser av klassen NSManagedObject.

Det diagram som vi utforskade tidigare visar att den hanterade objektkontexten tar emot modellobjekt via en koordinator för persistenta lager. Den behåller en referens till applikationens koordinator för persistent store.

Den hanterade objektkontexten är det objekt som du interagerar mest med. Den skapar, läser, uppdaterar och tar bort modellobjekt. Ur ett utvecklarperspektiv är NSManagedObjectContext-klassen arbetshästen i Core Data-ramverket.

Persistent Store Coordinator

Den persistenta lagringskoordinatorn representeras av en instans av NSPersistentStoreCoordinator-klassen och spelar en nyckelroll i varje Core Data-applikation. Även om det är möjligt att ha flera koordinatorer för persistenta lager har de flesta tillämpningar endast en. Det är mycket, mycket sällan som det finns ett behov av att ha flera koordinatorer för persistent store i ett program.

Koordinatorn för persistent store håller en referens till den hanterade objektmodellen och varje överordnat hanterat objektkontext håller en referens till koordinatorn för persistent store. Oroa dig inte för överordnade och underordnade hanterade objektkontexter för tillfället.

Diagrammet ovan visar att en koordinator för beständigt lager är ansluten till ett eller flera beständiga lager. Detta för oss till det persistenta lagret.

Persistent Store

Håller vi i minnet att Core Data hanterar ett objektdiagram. Ramverket är endast användbart om koordinatorn för det beständiga lagret är ansluten till ett eller flera beständiga lager. Core Data har stöd för tre typer av persistenta arkiv:

• en SQLite-databas
• ett binärt arkiv

– ett arkiv i minnet

Varje typ av persistent arkiv har sina för- och nackdelar. De flesta program använder en SQLite-databas som beständigt lager. Som jag nämnde tidigare är SQLite lättviktigt och mycket snabbt. Den är utmärkt för mobila och stationära applikationer.

Hur fungerar Core Data Stack

När du nu vet vad Core Data Stack består av är det dags att utforska hur den fungerar i en applikation. Hjärtat i en Core Data-applikation är koordinatorn för det beständiga lagret. Den persistent store coordinatorn instansieras först när Core Data-stacken skapas.

Men för att skapa den persistent store coordinatorn behöver vi en managed object model. Varför det? Samordnaren för persistent store måste veta hur dataskemat i programmet ser ut.

Efter att ha inrättat koordinatorn för persistent store och den hanterade objektmodellen initialiseras Core Data stackens arbetshäst, managed object context. Kom ihåg att en managed object context håller en referens till koordinatorn för persistent store.

Med Core Data-stacken konfigurerad är programmet redo att använda Core Data för att interagera med programmets persistent store. I de flesta fall interagerar programmet med koordinatorn för det beständiga lagret genom den hanterade objektkontexten.

Du kommer sällan, om ens någonsin, att interagera direkt med koordinatorn för det beständiga lagret eller den hanterade objektmodellen. Som jag nämnde tidigare är NSManagedObjectContext-klassen den klass du interagerar med mest frekvent.

Den hanterade objektkontexten används för att skapa, läsa, uppdatera och radera poster. När de ändringar som görs i den hanterade objektkontexten sparas, skickar den hanterade objektkontexten dem till koordinatorn för persistent store, som skickar ändringarna till motsvarande persistent store.

Om din applikation har flera persistenta arkiv räknar koordinatorn för persistenta arkiv ut vilket persistent arkiv som behöver lagra ändringarna i den hanterade objektkontexten.

In a Nutshell

Du känner nu till grunderna för Core Data-ramen. Du ligger redan före eftersom de flesta utvecklare hoppar över det här steget. Nästa steg du behöver ta är att börja använda ramverket. Om du behöver hjälp rekommenderar jag att du läser Mastering Core Data With Swift.

.