我有一个正在运行的应用程序，但我不满意我已经拥有最好（或最简单）的解决方案。该应用程序有一个数据库，其中包含许多具有典型一对多引用的表。到目前为止，这么好，并没有什么不寻常的。
该应用有3个标签，每个标签可以显示其中一个表的记录列表。如果用户触摸表格行，则选项卡上的导航视图会推送显示详细信息的新表格视图。想想你的地址簿，你就明白了。
在记录的详细信息视图中，我有一些部分包含其他表中记录的链接。因此，触摸一个将导航到该记录，更改为相应的选项卡。
编辑记录时很棘手，因为它会影响另一个选项卡上显示的数据。最初，我研究了根据核心数据保存通知发送的核心数据更改对表视图执行更新。但是我发现，根据这一点制定表格视图需要进行哪些更改太困难和不可靠。主要是因为我没有前后数据图进行比较。因此，当核心数据保存发生时，表视图只记得他们的后备数据可能已经受到影响，并且他们会在下一个显示器上完全重新加载。
虽然我的系统用于保持表视图中的数据同步，但我确信必须有更好的方法。我正在考虑KVO是否是更好的选择，表视图控制器跟踪数据图中的各个字段和对象，以便它们可以响应由其他表视图触发的精确更改。核心数据通知方法感觉有点像锤子方法来解决需要微妙挖掘的问题。
其他人如何处理这类问题？
答案 0 :(得分：2)
您的混淆是因为您试图在SQL / Relational-DB术语中考虑核心数据。
核心数据不是SQL。实体不是表格。对象不是行。列不是属性。核心数据是一个对象图管理系统，可能会或可能不会持久保存对象图，并且可能会或可能不会使用远远落后的SQL来执行此操作。试图用SQL术语来思考核心数据将导致你完全误解核心数据并导致更多的悲伤和浪费时间。
您的问题的解决方案很简单：您只需让所有选项卡使用相同的managedObjectContext。如果每个tableview由NSFetchedResultsController填充，FRC应该使用其他选项卡视图中的更改自动更新每个选项卡的tableview，因为FRC自动接收managedObjectContext通知。
无论如何，通知都是可行的方法。例如，如果您在一个选项卡中显示了一个托管对象，而该另一个选项卡在另一个选项卡中进行了编辑，则可以让该选项卡的活动视图控制器注册NSManagedObjectContextObjectsDidChangeNotification。
但是，您可能想要更改设计。界面语法没有教导用户期望在另一个选项卡中出现的更改会产生很多副作用。它也不会自动切换标签。只应在用户操作下更改选项卡。