Używanie podklas NSManagedObject do transportu trwałych i nietrwałych danych

Question

Mam kilka myśli na temat wykorzystania podklas NSManagedObject podstawowych danych do obsługi trwałych danych i nietrwałych danych.

Załóżmy, że masz aplikację do przepisywania, wyświetlającą listę własnych przepisów z CoreData, a w tej samej aplikacji możesz szukać także innych przepisów dla użytkowników. Te przepisy dla innych użytkowników są oczywiście z API i nie chcemy ich zapisywać w podstawowych danych. Ale zamiast tego chcemy szczegółowo opisać naszą recepturę, aby kontroler działał tak samo, albo otrzyma trwałą recepturę, albo nietrwałą recepturę. Naturalnie uważam, że powinniśmy użyć tego samego opakowania obiektu wokół naszych danych i pozwolić, aby nasz kontroler widoku był ślepy na pochodzenie danych.

Problem polega na tym, że podklas NSManagedObject nie można zainicjować ręcznie i trzeba go wstawić do kontekstu. To nie jest dobre dla naszych przepisów dla innych użytkowników. Z drugiej strony dla naszych własnych receptur potrzebujemy, aby ten obiekt został wstawiony w kontekst.

Mam na myśli kilka rozwiązań, ale naprawdę chciałbym przeczytać, co o nich myślisz.

Czy można powiedzieć, że jest to problem z implementacją i należy go rozwiązać, owijając oba obiekty danych w jeden pojedynczy obiekt? Na przykład przez przesłonięcie wszystkich modułów pobierających i ustawiających w celu obsługi zarówno obiektów coredata, jak i obiektów NSDictionary?

A może jest to problem z architekturą i można go rozwiązać, na przykład zagnieżdżając NSManagedContext lub używając wielu trwałych sklepów (jeden w pamięci i drugi Sqlite)?

Answer 1

W rzeczywistości można utworzyć wystąpienia NSManagedObject bez wstawiania ich do kontekstu. Wystarczy podać nil jako argument kontekstu obiektu zarządzanego. Zrób coś takiego:

NSEntityDescription *myRecipeEntity = [NSEntityDescription entityForName:@"MyRecipeEntity" inManagedObjectContext:[self managedObjectContext]]; 
MyRecipeClass *recipe = [[MyRecipeClass alloc] initWithEntity:myRecipeEntity insertIntoManagedObjectContext:nil]]; 

Teraz masz instancję receptury, której nie ma w żadnym kontekście.

Jeśli później chcesz dodać go do kontekstu:

[[self managedObjectContext] insertObject:recipe]; 

Jeśli nie chcesz go wstawić, po prostu wyrzucić.

Answer 2

Najprawdopodobniej użyłbym oddzielnego kontekstu, którego nigdy nie zapisałeś, co wydaje się być najprostszą trasą.

Answer 3

Konfiguracje modeli - magazyn w pamięci i magazyn zabezpieczony sqlite.

Chciałbym poważnie rozważyć użycie konfiguracji modelu i dwóch stałych typów magazynów: w pamięci i sqlite z kopią zapasową.

Ale oznacza to również, że trzeba by utworzyć oddzielne elementy do pobrania danych, które niweczą pomysł, że niektóre z receptur mogą być trwałe i tymczasowe, gdy oba są recepturami. Ponadto nie można utrzymywać relacji między jednostkami w różnych magazynach trwałych. Zrezygnujesz z korzyści odwrotnych relacji i będziesz musiał naśladować to na przykład przy pobieranych właściwościach.

Podsumowując, jest to opłacalny wybór z pewnymi wadami.

Odosobnione Kontekst zarządzanego obiektu

Największą zaletą korzystania z oddzielnych kontekstów zarządzanego obiektu jest to, można użyć tego samego podmiotu przepis na obu danych trwałych i tymczasowych. Będziesz musiał unikać zapisywania tymczasowego kontekstu i będziesz musiał wprowadzić wszystkie zmiany z magazynu trwałego lub scalić z innym kontekstem, który zawiera dane, które zapisujesz.

Wyzwaniem dla tej alternatywy jest to, że musisz zbudować większość swojego interfejsu użytkownika na tym odizolowanym kontekście do czytania, ale wszystkie trwałe zmiany, które wprowadzasz, muszą zostać zapisane w głównym kontekście i propagowane przez scalenie w izolowane kontekst. To może wprowadzić pewne trudne sytuacje, ale jest to wykonalne, jak sądzę.