Дизайн шаблона для Core Data iPhone App

Question

Im создание приложения, которое будет использовать модель Core Data. Я довольно новичок в Objective C, и мои обычные шаблоны проектирования на самом деле не применяются к Core Data и Objective C, по крайней мере, я не могу найти примеры, подтверждающие, что они будут.

Я прошел через примеры Apple Developer и различные источники на межтрубках.

кажется, что использовать Core Data мне нужно передать managedObjectContext каждому из моих viewControllers, есть ViewController реализовать NSFetchedResultsControllerDelegate, а затем реализовать каждый из методов делать выборки, а затем реализовать

NSFetchedResultsChangeInsert 

NSFetchedResultsChangeDelete NSFetchedResultsChangeMove NSFetchedResultsChangeUpdate

Это добавляет примерно 100+ строк кода в каждом ViewController и это 90% тот же код, я снова и снова писать. Плюс я должен пройти все вокруг и следить за его памятью.

На других языках я бы построил одноэлементную модель нескольких классов, в которой хранились методы для обслуживания и доставки данных по запросу, доступные из любого места. Кажется, я не могу принять такой подход в Objective C. Если мне нужно построить статический класс, который взял управляемый объектObjectContext и вернул мне то, что мне было нужно, мне все равно пришлось бы передавать managedObjectContext для каждого представления, и это не было бы асинхронно, когда я реализую методы делегата, которые просто вызываются, когда результат готов.

Надеюсь, что это имеет смысл и что кто-то может подтвердить, что нет другого разумного способа сделать это или помочь мне указать направление, чтобы оно было хорошо обернуто.

спасибо :)

Answer 1

основных данных не так сложно, как вы описываете.

Как правило, приложение iPhone имеет «основной» контекст управляемого объекта, который обычно принадлежит делегату приложения. Пока вы можете получить делегат приложения (подсказка: [[UIApplication sharedApplication] delegate]), у вас есть доступ к контексту управляемого объекта. Мне нравится определять статическую глобальную переменную, чтобы содержать ссылку на делегата моего приложения, чтобы облегчить жизнь.

В общем случае существует взаимно однозначное соответствие между NSFetchedResultsController экземплярами и UITableView экземплярами. Помимо заселения таблиц, крайне редко вам понадобится NSFetchedResultsController. Если у вас есть несколько похожих представлений (например, панель вкладок, позволяющая просматривать одни и те же данные по-другому в приложении iPod), вам нужно создать один базовый класс, который настраивает и выводит ваши конкретные контроллеры представлений От этого.

Теперь, когда вы создаете контроллеры представлений для редактирования объекта, в целом это хорошая идея сделать это в отдельном контексте управляемых объектов. Если пользователь отменяет, вы просто отбрасываете контекст, и изменения исчезают. Опять же, вам действительно не нужен NSFetchedResultsController, потому что эти представления касаются только одного объекта.

Когда вы закончите редактирование, вы обмениваете контекст управляемого объекта save:. Объекты, которые управляют вашими другими контекстами управляемых объектов, должны реализовать методы NSFetchedResultsControllerDelegate, чтобы синхронизировать представление таблицы. Опять же, это может быть реализовано в базовом классе, поэтому вы можете обобщить эту функциональность для связанных контроллеров представлений.

Answer 2

Нужно ли использовать модель CoreData или что-то, использующее NSCoder (NSArchiver, NSKeyedArchiver и т. Д.)? Я обнаружил, что CoreData слишком много для большинства приложений.

Кроме того, не могли бы вы пояснить, почему вы не можете использовать подход, используя одиночные игры? Я использовал одиночные фабрики в ряде приложений без проблем. Достаточно легко определить методы уровня класса, которые работают с общим экземпляром (singleton).