An Introductory Core Data Tutorial

Jeśli to czytasz, to zakładam, że jesteś nowy w Core Data. Być może słyszałeś o Core Data i chciałbyś dowiedzieć się, czy jest to dobre rozwiązanie dla Ciebie lub projektu, nad którym pracujesz. Jeśli ten opis pasuje do Ciebie, to usiądź. Ten samouczek Core Data nauczy cię wszystkiego, co musisz wiedzieć, aby lepiej zrozumieć czym jest i czym nie jest Core Data.

Czym jest Core Data

Deweloperzy, którzy dopiero poznają framework, bardzo często nie poświęcają czasu, aby dowiedzieć się czym jest Core Data. Nie wiedząc czym jest Core Data, bardzo trudno jest zrozumieć jego tajniki. Chciałbym poświęcić kilka minut na zbadanie natury Core Data i, co ważniejsze, wyjaśnienie czym Core Data jest, a czym nie jest.

Jakie są jego początki

Core Data to framework opracowany i utrzymywany przez Apple. Istnieje od ponad dekady i po raz pierwszy pojawił się w systemie macOS wraz z wydaniem macOS Tiger w 2005 roku. W 2009 roku firma udostępniła framework na iOS wraz z wydaniem iOS 3.

Gdzie on pasuje

Core Data to M w MVC, warstwa modelu Twojej aplikacji. Nawet jeśli Core Data może zapisywać dane na dysku, to jest to opcjonalna cecha frameworka. Core Data jest przede wszystkim frameworkiem do zarządzania grafem obiektów.

Prawdopodobnie słyszałeś i czytałeś o Core Data przed rozpoczęciem tego kursu. Oznacza to, że możesz już wiedzieć, że Core Data nie jest bazą danych i że zarządza grafem obiektów Twojej aplikacji. Oba te stwierdzenia są prawdziwe. Ale co one tak naprawdę oznaczają?

Zarządzanie grafem obiektów

Core Data przede wszystkim zarządza grafem obiektów. Graf obiektów to nic innego jak zbiór obiektów, które są ze sobą połączone. Core Data doskonale radzi sobie z zarządzaniem złożonymi grafami obiektowymi.

Zajmuje się zarządzaniem cyklem życia obiektów w grafie obiektowym i może opcjonalnie utrzymywać graf obiektowy na dysku. Oferuje również potężny interfejs do przeszukiwania grafu obiektów, którym zarządza.

Ale Core Data to znacznie więcej. Framework dodaje wiele innych atrakcyjnych funkcji, takich jak sprawdzanie poprawności danych wejściowych, wersjonowanie modelu danych i śledzenie zmian.

Kiedy używać Core Data

Szkielet ten doskonale pasuje do szerokiej gamy aplikacji, ale nie każda aplikacja powinna używać Core Data. Aplikacje, które potrzebują lekkiej warstwy modelu nie powinny używać Core Data. Istnieje wiele lekkich bibliotek, które zapewniają tego typu funkcjonalność.

Jeśli szukasz wrappera SQLite, to Core Data również nie jest tym, czego potrzebujesz. Jeśli chodzi o lekki, wydajny wrapper SQLite, gorąco polecam FMDB Gusa Muellera. Ta solidna, dojrzała biblioteka zapewnia obiektowy interfejs do interakcji z SQLite.

Core Data jest doskonałym wyborem, jeśli chcesz rozwiązania, które zarządza warstwą modelu Twojej aplikacji.

Jak to się różni od SQLite

Deweloperzy, którzy dopiero poznają Core Data, są często zdezorientowani różnicami między SQLite a Core Data. Jeśli zastanawiasz się, czy potrzebujesz SQLite czy Core Data, to zadajesz złe pytanie. Pamiętaj, że Core Data nie jest bazą danych.

SQLite

SQLite jest lekką bazą danych, która jest bardzo wydajna i dlatego dobrze nadaje się do aplikacji mobilnych. Nawet jeśli SQLite jest reklamowany jako relacyjna baza danych, ważne jest, aby zdać sobie sprawę, że to Ty, programista, jesteś odpowiedzialny za utrzymywanie relacji między rekordami przechowywanymi w bazie danych.

Core Data

Core Data idzie znacznie dalej. Zapewnia abstrakcję, która pozwala na interakcję z warstwą modelu w sposób zorientowany obiektowo. Każdy rekord, z którym wchodzisz w interakcję jest obiektem. Core Data jest odpowiedzialny za integralność grafu obiektów. Zapewnia, że graf obiektów jest aktualizowany na bieżąco.

Ograniczenia Core Data

Mimo że Core Data jest fantastycznym frameworkiem, ma kilka wad. Wady te są bezpośrednio związane z naturą frameworka i sposobem jego działania.

Core Data może czynić swoją magię tylko dlatego, że utrzymuje graf obiektów, którym zarządza w pamięci. Oznacza to, że może operować na rekordach tylko wtedy, gdy są one w pamięci. Różni się to bardzo od wykonywania zapytań SQL do bazy danych. Jeśli chcesz usunąć tysiące rekordów, Core Data musi najpierw załadować każdy z nich do pamięci. Nie trzeba dodawać, że powoduje to problemy z pamięcią i wydajnością, jeśli zostanie wykonane niepoprawnie.

Innym ważnym ograniczeniem jest model gwintowania Core Data. Ramy oczekują, że będą uruchamiane na jednym wątku. Na szczęście, Core Data ewoluował dramatycznie na przestrzeni lat i framework wprowadził różne rozwiązania, aby praca z Core Data w środowisku wielowątkowym była bezpieczniejsza i łatwiejsza.

Dla aplikacji, które muszą zarządzać złożonym grafem obiektów, Core Data jest świetnym rozwiązaniem. Jeśli potrzebujesz przechowywać tylko garść niepowiązanych ze sobą obiektów, wtedy możesz lepiej poradzić sobie z lekkim rozwiązaniem lub systemem domyślnych ustawień użytkownika.

Poznanie stosu Core Data

Teraz, gdy już wiesz, czym jest i czym nie jest Core Data, nadszedł czas, aby przybliżyć elementy składowe frameworka. Istotne jest, aby zrozumieć, jak różne klasy, które tworzą szkielet, grają razem.

Gwiazdami szkieletu są:

• zarządzany model obiektowy
• kontekst zarządzanego obiektu
• i koordynator stałego sklepu

Ten diagram pokazuje, jak te klasy odnoszą się do siebie nawzajem. Zacznijmy od zarządzanego modelu obiektowego.

Zarządzany model obiektowy

Zarządzany model obiektowy jest instancją klasy NSManagedObjectModel. Chociaż typowa aplikacja Core Data ma jedną instancję klasy NSManagedObjectModel, możliwe jest posiadanie wielu. Instancja zarządzanego modelu obiektowego reprezentuje model danych aplikacji Core Data.

Powyższy diagram pokazuje, że zarządzany model obiektowy jest połączony z modelem danych. Model danych jest reprezentowany przez plik w pakiecie aplikacji, który zawiera schemat danych aplikacji. Schemat danych to nic innego jak zbiór encji.

Encja może posiadać atrybuty i relacje, które składają się na model danych aplikacji. Zapamiętaj na razie, że model obiektu zarządzanego an instancja jest klasy NSManagedObjectModel i to ona model danych aplikacji Core Data reprezentuje.

Kontekst obiektu zarządzanego

Kontekst obiektu zarządzanego jest reprezentowany przez instancję klasy NSManagedObjectContext. Aplikacja Core Data ma jeden lub więcej zarządzanych kontekstów obiektów, z których każdy zarządza kolekcją obiektów modelu, instancji klasy NSManagedObject.

Schemat, który badaliśmy wcześniej, ilustruje, że zarządzany kontekst obiektów otrzymuje obiekty modelu za pośrednictwem koordynatora persystentnego sklepu. Utrzymuje on odniesienie do koordynatora trwałego magazynu aplikacji.

Kontekst zarządzanego obiektu jest obiektem, z którym użytkownik wchodzi w największą interakcję. Tworzy, odczytuje, aktualizuje i usuwa obiekty modelu. Z punktu widzenia programisty klasa NSManagedObjectContext jest koniem roboczym frameworka Core Data.

Koordynator persystentnego sklepu

Koordynator persystentnego sklepu jest reprezentowany przez instancję klasy NSPersistentStoreCoordinator i odgrywa kluczową rolę w każdej aplikacji Core Data. Chociaż możliwe jest posiadanie wielu koordynatorów persistent store, większość aplikacji ma tylko jednego. Bardzo, bardzo rzadko istnieje potrzeba posiadania wielu koordynatorów persistent store w aplikacji.

Koordynator persistent store przechowuje referencję do zarządzanego modelu obiektu, a każdy rodzicielski kontekst zarządzanego obiektu przechowuje referencję do koordynatora persistent store. Nie martw się o rodzica i dziecko zarządzanych kontekstów obiektów na razie.

Powyższy diagram pokazuje nam, że koordynator persistent store jest podłączony do jednego lub więcej persistent store. To prowadzi nas do persistent store.

Persistent Store

Pamiętajmy, że Core Data zarządza grafem obiektów. Framework jest użyteczny tylko wtedy, gdy koordynator persistent store jest podłączony do jednego lub więcej persistent store. Po wyjęciu z pudełka, Core Data obsługuje trzy typy persistent store:

• baza danych SQLite
• sklep binarny

-sklep w pamięci

Każdy typ persistent store ma swoje wady i zalety. Większość aplikacji używa bazy danych SQLite jako swojego trwałego magazynu. Jak wspomniałem wcześniej, SQLite jest lekki i bardzo szybki. Świetnie sprawdza się w aplikacjach mobilnych i desktopowych.

Jak działa stos Core Data

Teraz, gdy już wiesz, z czego składa się stos Core Data, czas zbadać, jak działa on w aplikacji. Sercem aplikacji Core Data jest koordynator stałego magazynu (persistent store coordinator). Koordynator jest tworzony jako pierwszy, gdy tworzony jest stos Core Data.

Ale do stworzenia koordynatora persistent store potrzebujemy zarządzanego modelu obiektowego. Dlaczego tak jest? Koordynator persistent store musi wiedzieć, jak wygląda schemat danych w aplikacji.

Po skonfigurowaniu koordynatora persistent store i zarządzanego modelu obiektu, inicjalizowany jest koń roboczy stosu Core Data, zarządzany kontekst obiektu. Pamiętaj, że kontekst obiektu zarządzanego przechowuje referencję do koordynatora persistent store.

Po skonfigurowaniu stosu Core Data, aplikacja jest gotowa do użycia Core Data do interakcji z persistent store aplikacji. W większości przypadków aplikacja wchodzi w interakcję z koordynatorem persistent store poprzez zarządzany kontekst obiektowy.

Rzadko, jeśli w ogóle, będziesz wchodził w bezpośrednią interakcję z koordynatorem persistent store lub zarządzanym modelem obiektowym. Jak wspomniałem wcześniej, klasa NSManagedObjectContext jest klasą, z którą najczęściej wchodzisz w interakcję.

Kontekst obiektu zarządzanego jest używany do tworzenia, odczytu, aktualizacji i usuwania rekordów. Kiedy zmiany dokonane w zarządzanym kontekście obiektów są zapisywane, zarządzany kontekst obiektów przesyła je do koordynatora persistent store, który wysyła zmiany do odpowiedniego persistent store.

Jeśli twoja aplikacja ma wiele persistent store, koordynator persistent store określa, który persistent store musi przechowywać zmiany w zarządzanym kontekście obiektowym.

W skrócie

Teraz znasz podstawy frameworka Core Data. Jesteś już na początku drogi, ponieważ większość programistów pomija ten krok. Następnym krokiem, który musisz podjąć jest rozpoczęcie korzystania z frameworka. Jeśli potrzebujesz pomocy, polecam sprawdzenie Mastering Core Data With Swift.

.