在没有 UITableView 的情况下使用 NSFetchedResultsController [英] Using NSFetchedResultsController Without UITableView

问题描述

纯粹将 NSFetchedResultsController 用于数据管理，即不使用它来提供 UITableView 是否错误?

Is it wrong to use an NSFetchedResultsController purely for data management, i.e., without using it to feed a UITableView?

我在 Core Data iPhone 应用中有一对多的关系.每当该关系中的数据发生变化时，我都需要执行需要对数据进行排序的计算.在 Apple 的标准部门/员工示例中，这就像确定给定部门的工资中位数.每当该部门增加或删除员工，或者员工的工资发生变化时，都需要重新计算中位数.

I have a to-many relationship in a Core Data iPhone app. Whenever data in that relationship changes, I need to perform a calculation which requires that data to be sorted. In Apple's standard Department/Employees example, this would be like determining the median salary in a given Department. Whenever an Employee is added to or removed from that Department, or an Employee's salary changes, the median calculation would need to be performed again.

保持数据排序和最新并在数据发生变化时收到通知对于 NSFetchedResultsController 来说听起来很棒.唯一的问题"是我没有使用 UITableView.换句话说，我没有在 UITableView 中显示已排序的员工.我只想要一个最新的员工排序数组，以便我可以在幕后分析他们.(当然，我不想写一堆重复NSFetchedResultsController的代码.)

Keeping data sorted and current and getting notifications when it changes sounds like a great job for NSFetchedResultsController. The only "problem" is that I'm not using a UITableView. In other words, I'm not displaying sorted Employees in a UITableView. I just want an up-to-date sorted array of Employees so I can analyze them behind the scenes. (And, of course, I don't want to write a bunch of code that duplicates much of NSFetchedResultsController.)

纯粹将 NSFetchedResultsController 用于数据管理，即不使用它来提供 UITableView 是否是一个坏主意?我还没有在任何地方看到过这种情况，我想我可能会遗漏一些东西.

Is it a bad idea to use an NSFetchedResultsController purely for data management, i.e., without using it to feed a UITableView? I haven't seen this done anywhere, and thought I might be missing something.

推荐答案

我不会说它不好，但绝对沉重".

I would not call it bad but definitely "heavy".

通过 NSManagedObjectContextDidSaveNotification 观察保存并在那里进行计算会减少内存和 CPU.该通知将在其 userInfo 中附带三个 NSArray 实例，然后您可以对这些数组使用一个简单的 NSPredicate 来查看您是否有任何员工关心已经改变并做出回应.

It would be less memory and CPU to watch for saves via the NSManagedObjectContextDidSaveNotification and do the calculation there. The notification will come with three NSArray instances in its userInfo and you can then use a simple NSPredicate against those arrays to see if any employee that you care about has changed and respond.

这是 NSFetchedResultsController 在幕后所做的工作的一部分.但是，您将避免使用您不关心或不需要的 NSFetchedResultsController 的其他部分.

This is part of what the NSFetchedResultsController does under the covers. However you would be avoiding the other portions of the NSFetchedResultsController that you don't care about or need.

NSFetchedResultsController 进行的处理不仅仅是观察保存的对象.它处理增量，调用其代表等.我不是说它在任何形式或形式上都不好.我的意思是，如果你只关心你关系中的对象何时发生变化，你可以很容易地通过观察通知来做到这一点.

NSFetchedResultsController does more processing than just watch for saved objects. It handles deltas, makes calls to its delegates, etc. I am not saying it is bad in any way shape or form. What I am saying is that if you only care about when objects have changed in your relationship, you can do it pretty easily by just watching for the notifications.

此外，没有理由保留任何内容，因为您已经持有部门"实体并因此访问其关系.持有子对象以防万一"是浪费内存.让 Core Data 管理内存，这是使用它的部分原因.

In addition, there is no reason to retain anything since you are already holding onto the "Department" entity and therefore access its relationships. Holding onto the child objects "just in case" is a waste of memory. Let Core Data manage the memory, that is part of the reason for using it.

这篇关于在没有 UITableView 的情况下使用 NSFetchedResultsController的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！