Использование NSFetchedResultsController без UITableView - PullRequest
10 голосов
/ 10 июля 2010

Неправильно ли использовать NSFetchedResultsController исключительно для управления данными, т. Е. Без использования его для подачи UITableView?

У меня есть отношение ко многим в приложении Core Data для iPhone.Всякий раз, когда изменяются данные в этом отношении, мне нужно выполнить вычисление, которое требует, чтобы эти данные были отсортированы.В стандартном примере Apple Department / Employees это похоже на определение средней зарплаты в данном отделе.Всякий раз, когда сотрудник добавляется в этот отдел или удаляется из него, или при изменении заработной платы сотрудника, вычисление медианы необходимо будет выполнять снова.

Поддержание сортировки данных в актуальном состоянии и получение уведомлений при их изменении звучит как большая работадля NSFetchedResultsController.Единственная «проблема» в том, что я не использую UITableView.Другими словами, я не отображаю отсортированных сотрудников в UITableView.Мне просто нужен обновленный отсортированный массив сотрудников, чтобы я мог анализировать их за кулисами.(И, конечно, я не хочу писать кучу кода, который дублирует большую часть NSFetchedResultsController.)

Это плохая идея использовать NSFetchedResultsController исключительно для управления данными, т.е.без использования его, чтобы накормить UITableView?Я нигде не видел, чтобы это было сделано, и подумал, что, возможно, что-то упустил.

Ответы [ 3 ]

11 голосов
/ 10 июля 2010

Я бы не назвал это плохим, но определенно "тяжелым".

Было бы меньше памяти и ЦП, чтобы следить за сохранением через NSManagedObjectContextDidSaveNotification и делать там вычисления. Уведомление будет содержать три NSArray экземпляра в его userInfo, и затем вы сможете использовать простое NSPredicate для этих массивов, чтобы увидеть, изменился ли какой-либо сотрудник, который вам нужен, и ответить.

Это часть того, что NSFetchedResultsController делает под одеялом. Однако вам следует избегать других частей NSFetchedResultsController, которые вам не нужны или вам не нужны.

Тяжелый

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

Память

Кроме того, нет никаких причин сохранять что-либо, поскольку вы уже держитесь за сущность «Отдел» и, следовательно, получаете доступ к ее отношениям. Держать дочерние объекты «на всякий случай» - пустая трата памяти. Позвольте Core Data управлять памятью, что является одной из причин ее использования.

0 голосов
/ 10 июля 2010

Для меня это звучит как правильное использование NSFetchedResultController.это может быть немного излишним, так как его основное использование - IS, чтобы помочь заполнять и обновлять tableViews, но если вы готовы мириться с добавленной сложностью, нет никаких причин не использовать его как таковой.Правильное использование уведомлений было бы другим методом, и это было бы так же сложно, как я мог бы оценить.

0 голосов
/ 10 июля 2010

Нет ничего плохого в использовании NSFetchedResultsController без представления.Ваш вариант использования звучит как хорошая причина не изобретать велосипед.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...