En introduktion til Core Data-vejledning

Hvis du læser dette, går jeg ud fra, at du er nybegynder inden for Core Data. Du har måske hørt om Core Data, og du vil gerne finde ud af, om det passer godt til dig eller det projekt, du arbejder på. Hvis denne beskrivelse passer på dig, så tag plads. Denne Core Data-tutorial lærer dig alt det, du skal vide for bedre at forstå, hvad Core Data er og ikke er.

Hvad er Core Data

Udviklere, der er nye inden for rammerne, tager sig meget ofte ikke tid til at lære, hvad Core Data er. Hvis man ikke ved, hvad Core Data er, er det meget svært at forstå, hvad det er for en størrelse. Jeg vil gerne bruge et par minutter på at udforske Core Datas natur og, endnu vigtigere, afklare, hvad Core Data er og ikke er.

Hvad er dets oprindelse

Core Data er en ramme, der er udviklet og vedligeholdt af Apple. Det har eksisteret i mere end et årti, og det dukkede første gang op på macOS med udgivelsen af macOS Tiger i 2005. I 2009 gjorde virksomheden rammen tilgængelig på iOS med udgivelsen af iOS 3.

Hvor passer det ind

Core Data er M’et i MVC, modellaget i din applikation. Selv om Core Data kan persistere data på disken, er datapersistens faktisk en valgfri funktion i rammen. Core Data er først og fremmest en ramme til håndtering af en objektgraf.

Du har sikkert hørt og læst om Core Data, før du har taget dette kursus. Det betyder, at du måske allerede ved, at Core Data ikke er en database, og at den administrerer din applikations objektgraf. Begge udsagn er sande. Men hvad betyder de egentlig?

Håndtering af en objektgraf

Core Data håndterer først og fremmest en objektgraf. En objektgraf er intet andet end en samling af objekter, der er forbundet med hinanden. Core Data-rammen udmærker sig ved at administrere komplekse objektgrafer.

Den sørger for at administrere livscyklussen for objekterne i objektgrafen, og den kan eventuelt persistere objektgrafen på disken. Den tilbyder også en kraftfuld grænseflade til søgning i den objektgraf, som den administrerer.

Men Core Data er meget mere end det. Rammerne tilføjer en række andre overbevisende funktioner, f.eks. inputvalidering, versionering af datamodeller og ændringssporing.

Hvornår skal man bruge Core Data

Rammen passer perfekt til en lang række programmer, men det er ikke alle programmer, der bør bruge Core Data. Applikationer, der har brug for et letvægtsmodellag, bør ikke bruge Core Data. Der findes mange letvægtsbiblioteker, der leverer denne type funktionalitet.

Hvis du leder efter en SQLite-wrapper, så er Core Data heller ikke det, du har brug for. For en let, performant SQLite-wrapper kan jeg varmt anbefale Gus Mueller’s FMDB. Dette robuste, modne bibliotek giver en objektorienteret grænseflade til interaktion med SQLite.

Core Data er et glimrende valg, hvis du ønsker en løsning, der administrerer modellaget i din applikation.

Hvordan adskiller det sig fra SQLite

Udviklere, der er nye i forhold til Core Data, bliver ofte forvirrede over forskellene mellem SQLite og Core Data. Hvis du spekulerer på, om du har brug for SQLite eller Core Data, så stiller du det forkerte spørgsmål. Husk, at Core Data ikke er en database.

SQLite

SQLite er en letvægtsdatabase, der er meget performant og derfor passer godt til mobilapplikationer. Selv om SQLite annonceres som en relationel database, er det vigtigt at være klar over, at det er dig som udvikler, der står for at vedligeholde relationerne mellem de poster, der er gemt i databasen.

Core Data

Core Data går meget længere. Det giver en abstraktion, der gør det muligt for dig at interagere med modellaget på en objektorienteret måde. Hver post, du interagerer med, er et objekt. Core Data er ansvarlig for integriteten af objektgrafen. Den sikrer, at objektgrafen holdes ajour.

Core Data Begrænsninger

Selv om Core Data er en fantastisk ramme, er der flere ulemper. Disse ulemper er direkte relateret til karakteren af rammen, og hvordan den fungerer.

Core Data kan kun udføre sin magi, fordi den holder den objektgraf, den administrerer, i hukommelsen. Det betyder, at den kun kan operere på registreringer, når de befinder sig i hukommelsen. Dette er meget forskelligt fra at udføre en SQL-forespørgsel på en database. Hvis du ønsker at slette tusindvis af poster, skal Core Data først indlæse hver enkelt post i hukommelsen. Det siger sig selv, at dette resulterer i hukommelses- og ydelsesproblemer, hvis det gøres forkert.

En anden vigtig begrænsning er Core Datas threading-model. Rammerne forventer at blive kørt på en enkelt tråd. Heldigvis har Core Data udviklet sig dramatisk gennem årene, og rammen har indført forskellige løsninger, der gør det mere sikkert og nemmere at arbejde med Core Data i et miljø med flere tråde.

For applikationer, der skal administrere en kompleks objektgraf, er Core Data et godt match. Hvis du kun skal gemme en håndfuld ikke-relaterede objekter, er du måske bedre tjent med en letvægtsløsning eller brugerstandardsystemet.

Udforskning af Core Data-stakken

Nu da du ved, hvad Core Data er, og hvad det ikke er, er det tid til at zoome ind på rammens byggeklodser. Det er vigtigt, at du forstår, hvordan de forskellige klasser, der får rammen til at fungere, spiller sammen.

Stjernerne i rammen er:

• den administrerede objektmodel
• den administrerede objektkontekst
• og den persistente lagerkoordinator

Dette diagram viser, hvordan disse klasser relaterer til hinanden. Lad os starte med den administrerede objektmodel.

Managed Object Model

Den administrerede objektmodel er en instans af NSManagedObjectModel-klassen. Mens et typisk Core Data-program har én instans af NSManagedObjectModel-klassen, er det muligt at have flere. Instansen af den administrerede objektmodel repræsenterer datamodellen for Core Data-applikationen.

Diagrammet ovenfor viser, at den administrerede objektmodel er forbundet med datamodellen. Datamodellen repræsenteres af en fil i applikationsbundlen, der indeholder applikationens dataskema. Dataskemaet er intet andet end en samling af entiteter.

En entitet kan have attributter og relationer, som udgør applikationens datamodel. Husk for nu, at den administrerede objektmodel en instans er af NSManagedObjectModel-klassen, og at det datamodellen i Core Data-applikationen repræsenterer.

Managed Object Context

En managed object context er repræsenteret af en instans af NSManagedObjectContext-klassen. En Core Data-applikation har en eller flere administrerede objektkontekster, der hver forvalter en samling af modelobjekter, som er instanser af NSManagedObject-klassen.

Det diagram, vi udforskede tidligere, illustrerer, at den administrerede objektkontekst modtager modelobjekter via en persistent butikskoordinator. Den beholder en reference til programmets persistent store-koordinator.

Den administrerede objektkontekst er det objekt, du interagerer mest med. Den opretter, læser, opdaterer og sletter modelobjekter. Set fra en udviklers perspektiv er NSManagedObjectContext-klassen arbejdshesten i Core Data-rammen.

Persistent Store Coordinator

Den persistente butikskoordinator repræsenteres af en instans af NSPersistentStoreCoordinator-klassen, og den spiller en nøglerolle i alle Core Data-programmer. Selv om det er muligt at have flere koordinatorer for vedvarende lagre, har de fleste programmer kun én. Det er meget, meget sjældent, at der er behov for at have flere persistent store-koordinatorer i en applikation.

Den persistent store-koordinator holder en reference til den administrerede objektmodel, og hver overordnet administreret objektkontekst holder en reference til den persistent store-koordinator. Du skal ikke bekymre dig om forælder- og underordnede administrerede objektkontekster for nu.

Overstående diagram viser os, at en persistent butikskoordinator er forbundet med en eller flere persistente lagre. Dette bringer os til det persistente lager.

Persistent Store

Husk, at Core Data administrerer en objektgraf. Rammerne er kun nyttige, hvis koordinatoren for persistente lagre er forbundet med et eller flere persistente lagre. Out of the box understøtter Core Data tre persistente lagertyper:

• en SQLite-database
• et binært lager

– et in-memory-lager

Hver enkelt persistent lagertype har sine fordele og ulemper. De fleste programmer bruger en SQLite-database som deres persistente lager. Som jeg nævnte tidligere, er SQLite let og meget hurtig. Den er fantastisk til mobile og stationære applikationer.

Hvordan fungerer Core Data Stack

Nu da du ved, hvad Core Data Stack består af, er det tid til at undersøge, hvordan den fungerer i et program. Hjertet i en Core Data-applikation er den persistente lagerkoordinator. Den persistente lagerkoordinator instantieres først, når Core Data-stakken oprettes.

Men for at oprette den persistente lagerkoordinator har vi brug for en administreret objektmodel. Hvorfor er det sådan? Den persistent store-koordinator skal vide, hvordan applikationens dataskema ser ud.

Når man har oprettet den persistent store-koordinator og den administrerede objektmodel, initialiseres arbejdshesten i Core Data stakken, nemlig den administrerede objektkontekst. Husk, at en administreret objektkontekst bevarer en reference til koordinatoren for det vedvarende lager.

Med Core Data-stakken konfigureret er programmet klar til at bruge Core Data til at interagere med programmets vedvarende lager. I de fleste tilfælde interagerer din applikation med koordinatoren for det vedvarende lager via den administrerede objektkontekst.

Du vil sjældent, hvis overhovedet nogensinde, interagere direkte med koordinatoren for det vedvarende lager eller den administrerede objektmodel. Som jeg nævnte tidligere, er NSManagedObjectContext-klassen den klasse, du interagerer med oftest.

Den administrerede objektkontekst bruges til at oprette, læse, opdatere og slette poster. Når de ændringer, der er foretaget i den administrerede objektkontekst, gemmes, skubber den administrerede objektkontekst dem til koordinatoren for det vedvarende lager, som sender ændringerne til det tilsvarende vedvarende lager.

Hvis din applikation har flere persistente lagre, finder koordinatoren for persistente lagre ud af, hvilket persistent lager der skal gemme ændringerne i den administrerede objektkontekst.

In a Nutshell

Du kender nu de grundlæggende elementer i Core Data-rammen. Du er allerede på forkant med udviklingen, fordi de fleste udviklere springer dette trin over. Det næste skridt, du skal tage, er at begynde at bruge rammen. Hvis du har brug for hjælp, anbefaler jeg, at du læser Mastering Core Data With Swift.