Punkt użycia NSPersistentStoreCoordinator?

Question

W wykładzie Core Data z kursu Stanford 193P na iTunes instruktor zakodował przykładowy projekt z danymi podstawowymi bez użycia NSPersistentStoreCoordinator i załadował go z NSManagedObjectModel. Ale patrząc na inne próbki kodu i książkę Big Nerd Ranch na temat rozwoju iPhone'a, tworzą one NSManagedObjectModel i PersistentStoreCoordinator i konfigurują w ten sposób NSManagedObjectContext.

Moje pytanie brzmi, jaki jest cel takiego postępowania i jakie są plusy i minusy obu podejść?

Answer 1

Bardzo dokładnie śledziłem tę serię wykładów. Ten konkretny przykład ściąga dane (fotografów i zdjęć) z Flickr i ładuje je do CoreData. Nie było konieczne używanie CoreData w tej aplikacji, ponieważ musi ona pobierać nowe dane z flickr przy każdym ładowaniu aplikacji, dlatego nie ma sensu oszczędzanie. Profesor właśnie używał aplikacji do pobierania flickr z poprzedniego demo jako punktu wyjścia, ponieważ studenci już ją znali (pozwalając mu skupić się na wyjaśnieniu CoreData). Jednakże, jak wspomniał Rickster, istnieją ogromne korzyści z używania podstawowych danych bez zapisywania kontekstu na dysku.

Jak Paweł wyjaśnił w wykładzie przed demo, baza rdzeń może być utworzony (w iOS5) albo przez:

1. Kliknięcie „Użyj danych core” dla szablonu aplikacji podczas tworzenia nowego projektu.
2. Korzystanie UIManagedDocument

Ideą pierwszego podejścia jest to, że Xcode wprowadzi kilka kodu w AppDelegate skonfigurować katalog Dokumenty/persistent koordynatora sklepu/i model. Następnie przekaże zarządzany obiekt CONTEXT do początkowego kontrolera widoku (który powinien mieć właściwość NSManagedObjectContext w publicznym interfejsie API), a stamtąd można przekazać kontekst jak butelkę piwa, gdy przenosisz się do innych kontrolerów view. Przekazywanie kontekstu jest poprawną procedurą dostępu do głównej bazy danych.

Użycie UIManagedDocument jest bardzo podobne, z tym wyjątkiem, że AppDelegate jest pozostawiony samemu sobie. Tworzysz UIManagedDocument (może w twoim początkowym kontrolerze widoku) używając ścieżki URL z katalogu dokumentu aplikacji (Uwaga: musisz ręcznie sprawdzić, czy plik już się kończy, istnieje, ale nie jest otwarty lub nie istnieje). Następnie możesz użyć kontekstu tego dokumentu w taki sam sposób jak powyżej.

Inna uwaga: Dobrym pomysłem jest utworzenie wskaźnika do kontekstu w AppDelegate, dzięki czemu można jawnie zapisać swój kontekst (tylko gdy jest gotowy!), Gdy aplikacja się zawiesza lub kończy.

Koordynator magazynu trwałego jest konfigurowany automatycznie i można go skonfigurować za pomocą właściwości persistentStoreOptions (i trzeba będzie w celu trwałego zapisania kontekstu) lub podklasy UIManagedDocument i nadpisanie pożądanych metod.

Przeczytaj przegląd w dokumentacji UIManagedDocument http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIManagedDocument_Class/Reference/Reference.html

Obie metody działają w ten sam sposób i zapewniają tym samym kontroli i dostępu. Dzięki UIManagedDocuments można tworzyć wiele baz danych w wielu plikach sqlite, można również poczekać na utworzenie/ustawienie bazy danych, aż do jej potrzeb. Opcja "Użyj danych podstawowych" zapewnia pojedynczą bazę danych, którą konfiguruje przy obciążeniu aplikacji, umożliwia scentralizowanie rzeczy CoreData wokół AppDelegate, oszczędza czas kodowania i jest dobra dla aplikacji szybkiej ścieżki. Lubię UIManagedDocument.

Jeśli uruchomiłeś aplikację bez zaznaczonej opcji danych podstawowych i chcesz ją dodać do AppDelegate, po prostu utwórz nowy projekt z zaznaczonymi podstawowymi danymi i skopiuj cały kod do AppDelegate (powinny to być tylko 3 właściwości i ich akcesory jak również wygodna metoda dostępu do katalogu dokumentów). Konieczne będzie wskazanie początkowego kontrolera widoku, modelu itp.

AKTUALIZACJA: Chciałem tylko dodać jeszcze jedną wygodę. Jeśli udało kontekst obiekt jest przechowywany w appDelegate, można do niego dostęp w dowolnym miejscu aplikacji tylko za pomocą

NSManagedObjectContext* context = [[(AppDelegate*) [UIApplication sharedApplication] delegate] myManagedObjectContext]; 

ten neguje konieczności przechodzenia go wokół.

W przypadku każdej aplikacji CoreData, jeśli wprowadzisz jakiekolwiek zmiany do swojego modelu, UPEWNIJ SIĘ, ŻE RĘCZNIE USUŃ APLIKACJĘ W SYMULATORZE, zanim zaczniesz ponownie. W przeciwnym razie pojawi się błąd w następnym kompilacji, ponieważ użyje starego pliku.

Answer 2

Bez trwałego koordynatora sklepu nie będzie można zapisać wyników w trwałym obszarze (baza danych, plik itp.) ... więc jeśli potrzebujesz stałego menedżera danych, który jest całkowicie bezużyteczny, pomiń NSPersistentStoreCoordinator. Czy jesteś pewien, że projekt go nie używał? Jak profesor zapisywał dane? Podczas tworzenia nowego projektu danych podstawowych ta logika jest automatycznie tworzona.

EDYCJA: Dostałem go teraz, profesor używa UIManagedDocument, który używa wewnętrznego koordynatora magazynu trwałego wewnętrznie (w oparciu o typ pliku), więc nie ma potrzeby tworzenia wyraźnego (chyba że nie jesteś zadowolony z domyślna). Ostatecznie nie chodzi o to, czy użyć koordynatora, ale o to, czy go jawnie utworzysz.