Wzorzec projektu dla iPhone'a Core Data

Question

Buduję aplikację, która będzie używać modelu Core Data. Jestem całkiem nowy w Objective C, a moje zwykłe wzorce projektowe tak naprawdę nie mają zastosowania w Core Data i Objective C, przynajmniej nie mogę znaleźć przykładów, które potwierdzą, że będą.

Przeszedłem przez Apple Developer przykłady i różne źródła na intertubes.

Wydaje się, że wykorzystanie danych Core muszę zdać managedObjectContext do każdego z moich viewControllers, mają viewController wdrożenia NSFetchedResultsControllerDelegate a następnie wdrożyć każdej z metod robi pobrać, a następnie wdrożyć

NSFetchedResultsChangeInsert 

NSFetchedResultsChangeDelete NSFetchedResultsChangeMove NSFetchedResultsChangeUpdate

dodaje około 100+ linii kodu w każdym viewController i to jest 90% ten sam kod jeszcze raz i jeszcze raz pisać. Poza tym muszę wszystko przekazać i śledzić jego ślad pamięci.

W innych językach chciałbym zbudować singletowy model kilku klas, który utrzymywałby metody utrzymywania i dostarczania danych na żądanie, dostępne z dowolnego miejsca. Wydaje się, że nie mogę przyjąć takiego podejścia w Celu C. Jeśli gdzie zbudować statyczną klasę, która zajęłaby obiekt managedObjectContext i zwrócił mi to, co było mi potrzebne, nadal musiałbym przekazać obiekt managedObjectContext do każdego widoku i nie byłby on asynchronicznie, podobnie jak w przypadku implementowania metod delegowania, które są wywoływane, gdy wynik jest gotowy.

Mam nadzieję, że to ma sens i że ktoś może potwierdzić, że nie ma innego rozsądnego sposobu, aby to zrobić, lub pomóc mi wskazać kierunek, w którym można to dobrze owijać.

Dzięki :)

Answer 1

Dane podstawowe nie są aż tak skomplikowane, jak opisujesz.

Zasadniczo aplikacja na telefon iPhone ma "główny" kontekst obiektu zarządzanego, który zazwyczaj należy do delegata aplikacji. Dopóki można uzyskać delegata aplikacji (wskazówka: [[UIApplication sharedApplication] delegate]), masz dostęp do kontekstu zarządzanego obiektu. Lubię definiować statyczną zmienną globalną, aby zachować odwołanie do mojego delegata aplikacji, aby ułatwić życie.

Istnieje ogólna relacja jeden-do-jednego między instancjami NSFetchedResultsController i instancjami UITableView. Oprócz zapełniania widoków tabel niezwykle rzadko zdarza się, że potrzebujesz NSFetchedResultsController. Jeśli masz wiele podobnych widoków (np. Pasek zakładek, który pozwala wyświetlać te same dane na różne sposoby, a la w aplikacji iPoda), należałoby utworzyć pojedynczą klasę podstawową, która konfiguruje NSFetchedResultsController i wyprowadzić określone kontrolery widoku z tego.

Teraz, gdy tworzysz kontrolery widoku, aby edytować obiekt, dobrym pomysłem jest zrobienie tego w oddzielnym kontekście obiektu zarządzanego. Jeśli użytkownik anuluje, po prostu odrzucisz kontekst, a zmiany znikną. Ponownie, naprawdę nie potrzebujesz do tego celu NSFetchedResultsController, ponieważ te widoki dotyczą tylko jednego obiektu.

Po zakończeniu edycji, użytkownik uzyskuje kontekst obiektu zarządzanego. Obiekty, które zarządzają innymi kontekstami obiektów zarządzanych, powinny implementować metody NSFetchedResultsControllerDelegate, aby synchronizować widok tabeli. Ponownie, można to zaimplementować w klasie bazowej, dzięki czemu można uogólnić tę funkcjonalność dla pokrewnych kontrolerów widoku.

Answer 2

Czy musisz bezwzględnie używać modelu CoreData, czy też przy użyciu NSCodera (NSArchiver, NSKeyedArchiver itp.)? Odkryłem, że CoreData jest przesadą dla większości aplikacji.

Czy można również wyjaśnić, dlaczego nie można zastosować podejścia wykorzystującego singletony? Używałem pojedynczych fabryk w wielu aplikacjach bez problemów. Jest dość łatwo zdefiniować metody na poziomie klasy, które działają na współużytkowanej (singleton) instancji.