ios - 对 CoreData 中的 1 个条目使用 Fetched Results Controller

Question

我有一个快速(或一般的 iOS)问题:

我的场景:

我有一张表格，每个单元格中都有化身(除其他外)。每个化身都有存在(可用/不可用)。每个单元格中其他内容的数据源不受 CoreData 支持(这是一个限制)并且与提供头像照片和状态的用户(在 CoreData 中)没有任何关系。 p>

所以我让我的头像成为一个 View ，它接受用户然后呈现用户的照片和状态。当用户的状态发生变化时(在 CoreData 中)，需要通知 View 以便它可以更新头像上的状态指示器。 (不要担心我的代码结构，我使用的是 MVC，但我简化了一些事情以避免对我的场景进行冗长的描述)。

我的问题:

使用 NSFetchedResultsController (FRC) 观察 CoreData 中的 1 个条目是否不好？有没有其他更适合这个的东西(因为 NSFetchedResultsController 真的适合 TableView )？

基本上我会做的是让化身使用 FRC 来监听其在 CoreData 中的用户的变化。因此，每个单元格中的每个化身都会有一个 FRC 来观察 1 个用户。以这种方式使用 FRC 对我来说似乎很奇怪。 (不用担心 cell 重用，当 cell 重用处理化身时，所有 FRC 也会被处理)。

其他选项:

我可以在我的用户 CoreData 存储管理器对象上设置一个观察者(委托(delegate))来监听特定用户的更改(存储管理器用于更新 CoreData 中的条目，以便对 CoreData 用户实体的所有更新都通过那)然后当观察者听到变化时，它可以通知与该用户相关联的代表(这将是化身)。但这本质上就像制作我自己的 FRC。这会因表格中的单元格重用而变得复杂(因为每个化身都在表格中的一个单元格中)，因为我认为我必须经常注册/取消注册代表。

我可以在用户存储的 MOC 上监听有关更改的任何通知(例如 NSManagedObjectContextObjectsDidChange)，但随后我将获得每个 用户的更改并且必须进行过滤。而且，我觉得这类似于重新实现 FRC，但效率可能较低，而且我可能还会遇到单元重用的复杂性。

总结:

我只是想获得有关监听数据库中唯一(按用户 ID)条目更改的最佳方法的建议。 FRC 是最好的方法，还是有更好的方法？

Answer 1

如果您有对 User 模型对象的引用，您可以对其属性进行 KVO。