Использование NSFetchedResultsController без UITableView
Разве неправильно использовать NSFetchedResultsController просто для управления данными, т.е. не используя его для питания a UITableView?
Я имею к - многие отношения в Базовом приложении для iPhone Данных. Каждый раз, когда данные в тех отношениях изменяются, я должен выполнить вычисление, которое требует что данные быть отсортированным. В стандартном примере Отдела/Сотрудников Apple это было бы похоже на определение средней зарплаты в данном Отделе. Каждый раз, когда Сотрудник добавлен к или удален из того Отдела или изменений зарплаты Сотрудника, среднее вычисление должно было бы быть выполнено снова.
Хранение данных, отсортированных и текущих и получение уведомлений, когда это изменяется, походят на отличную работу для NSFetchedResultsController. Единственная "проблема" состоит в том, что я не использую a UITableView. Другими словами, я не отображаю отсортированных Сотрудников в a UITableView. Я просто хочу актуальный сортированный массив Сотрудников, таким образом, я могу проанализировать их негласно. (И, конечно, я не хочу писать набор кода, который копирует большую часть из NSFetchedResultsController.)
Действительно ли это - плохая идея использовать NSFetchedResultsController просто для управления данными, т.е. не используя его для питания a UITableView? Я не видел сделанный нигде и думал, что мог бы пропускать что-то.
3 ответа
Я бы не назвал это плохим, но определенно «тяжелым».
Было бы меньше памяти и ЦП, чтобы следить за сохранениями через NSManagedObjectContextDidSaveNotification и выполнять там вычисления. Уведомление будет содержать три экземпляра NSArray в его userInfo , и затем вы можете использовать простой NSPredicate для этих массивов, чтобы узнать, есть ли у кого-нибудь из сотрудников, о которых вы заботитесь, поменял и отреагировал.
Это часть того, что скрыто делает NSFetchedResultsController . Однако вам следует избегать других частей NSFetchedResultsController , которые вам не нужны или которые вам не нужны.
Heavy
NSFetchedResultsController выполняет больше обработки, чем просто отслеживает сохраненные объекты. Он обрабатывает дельты, делает вызовы своим делегатам и т. Д. Я не говорю, что это плохо в какой-либо форме или форме. Я хочу сказать, что если вы только заботитесь об изменении объектов в ваших отношениях, вы можете сделать это довольно легко, просто наблюдая за уведомлениями.
Память
Кроме того, нет никаких причин для сохранения чего-либо, поскольку вы уже удерживаете объект «Отдел» и, следовательно, получаете доступ к его отношениям. Удержание дочерних объектов «на всякий случай» - пустая трата памяти. Позвольте Core Data управлять памятью, это одна из причин ее использования.
Для меня это звучит как подходящее использование NSFetchedResultController. это может быть немного излишним, поскольку его основное использование - это помощь в заполнении и обновлении tableViews, но если вы готовы мириться с дополнительной сложностью, нет причин не использовать его как таковой. Другим методом было бы правильное использование уведомлений, и я бы сказал, что он столь же сложен.
Нет ничего плохого в использовании NSFetchedResultsController без представления. Ваш вариант использования звучит как веская причина не изобретать колесо заново.