Core data iPhone设计:单个数据源的多个表视图

Core data iPhone设计:单个数据源的多个表视图,core-data,ios4,Core Data,Ios4,我有一个应用程序正在运行,但我不高兴我有最好(或最简单)的解决方案。该应用程序有一个数据库,其中包含多个具有典型一对多引用的表。到目前为止还不错,没有什么不寻常的 该应用程序有3个选项卡,每个选项卡可以显示其中一个表中的记录列表。如果用户触摸表格行,则选项卡上的导航视图将推送显示详细信息的新表格视图。想想你的通讯录,你就知道了 在记录的details视图中,我有一些部分包含指向其他表中记录的链接。因此,触摸一个将导航到该记录,并切换到相应的选项卡 棘手的一点是编辑记录时,因为它会影响另一个选项卡

我有一个应用程序正在运行,但我不高兴我有最好(或最简单)的解决方案。该应用程序有一个数据库,其中包含多个具有典型一对多引用的表。到目前为止还不错,没有什么不寻常的

该应用程序有3个选项卡,每个选项卡可以显示其中一个表中的记录列表。如果用户触摸表格行,则选项卡上的导航视图将推送显示详细信息的新表格视图。想想你的通讯录,你就知道了

在记录的details视图中,我有一些部分包含指向其他表中记录的链接。因此,触摸一个将导航到该记录,并切换到相应的选项卡

棘手的一点是编辑记录时,因为它会影响另一个选项卡上显示的数据。最初,我考虑根据从核心数据保存通知发送的核心数据更改来执行表视图更新。然而,我发现,根据这些信息确定需要对表视图进行哪些更改太困难,也不可靠。主要是因为我没有前后数据图来比较。因此,当前在进行核心数据保存时,表视图只需记住其备份数据可能已受到影响,并在下次显示时进行完全重新加载

虽然我的系统可以在表视图中保持数据同步,但我相信一定有更好的方法。我正在考虑KVO是否是更好的选择,因为表视图控制器跟踪数据图中的各个字段和对象,以便它们能够响应其他表视图触发的精确更改。核心数据通知方法感觉有点像是解决问题的锤子方法,需要一个微妙的攻关


其他人是如何处理这类问题的?

您的困惑是因为您试图用SQL/Relational DB术语来考虑核心数据

核心数据不是SQL。实体不是表。对象不是行。列不是属性。核心数据是一个对象图管理系统,它可以持久化对象图,也可以不持久化对象图,还可以在后台使用SQL来持久化对象图。试图用SQL术语来理解核心数据会导致您完全误解核心数据,并导致很多悲伤和浪费时间

问题的解决方案很简单:您只需让所有选项卡使用相同的managedObjectContext即可。如果每个tableview都由NSFetchedResultsController填充,则FRC应使用在其他选项卡视图中所做的更改自动更新每个选项卡的tableview,因为FRC会自动接收managedObjectContext通知

在任何情况下,通知都是一条出路。例如,如果一个选项卡中显示的托管对象在另一个选项卡中以某种方式进行编辑,则可以将该选项卡的活动视图控制器注册为
NSManagedObjectContextObjectsIDChangeNotification

但是,您可能需要更改设计。界面语法并没有教会用户从一个选项卡中的更改到另一个选项卡中的更改会产生很多副作用。它也不会自动切换制表符。只能在“用户操作”下更改选项卡