核心数据多级父 – 子上下文
在我的应用程序中，我有UITableViewController显示事件列表。 该控制器使用ManagedObjectContext说ParentContext 。 现在，如果select了任何事件，则会显示详细的视图控制器，用户可以在其中编辑事件的详细信息。 所以我创build了一个小孩的上下文说，
ChildContext with type "NSPrivateQueueConcurrencyType"
ChildContext whose parent Context is "ParentContext".
我的代码是：
NSManagedObjectContext *childContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType]; childContext.parentContext = self.context ;
现在又有一些领域和关系需要再次深入研究。 所以我为新的视图控制器创build了另一个ChildContext说，
GrandChildContext with type "NSPrivateQueueConcurrencyType"
GrandChildContext whose parent context is "ChildContext"
这个过程进行到另一个级别（从父级（tableView）到子级总共4级）
self.context - Parent Context | | ChildContext | | GrandChildContext | | GrandGrandChildContext
我的实体看起来像这样
EntityA -- ( Edit View Controller - uses ChildContext ) | |- Field1 | |- Field2 | |- RelationShip (1 to Many ) - ( Relationship Add / Edit View Controller - uses GrandChildContext ) | |- Field1 | . | . |- Field3 | |- Relationship ( 1 to Many ) - ( Relationship Add / Edit View Controller - uses GrandGrandChildContext ) | |- Field1 | |- Field2
这是使用父 – 子上下文的正确方法吗？ 因为在某个时间点，我将拥有1 NSMainQueueConcurrencyType MOC and 3 NSPrivateQueueConcurrencyType MOC 。
如果不是？ 有没有其他方法？
是否有太多的孩子情况影响应用程序的性能？
最初我使用属性和NSArrayspipe理用户input的数据，当用户点击完成button，我会更新/创buildpipe理对象。 但这是一个乏味的工作，它使我的视图控制器变得很脏。 所以我切换到父 – 子上下文，这是很容易保存/放弃更新。
谢谢
你可能已经在多个孩子背景下过了一点点，但只有一点儿，你的一般方法是正确的。 MOC（托pipe对象上下文）是一个相当轻量级的对象。
我喜欢你的方法，在每个视图控制器/场景中有一个独特的参考，适用于该场景的MOC。
将MOC视为会话或便笺簿有时很有帮助。 比赛不在MOC和实体之间，而在MOC和逻辑单位之间。
如果您的某个向下钻取标记了用户可能想要放弃/取消的某个编辑任务的开始，那么这是分离一个小孩MOC并将其传递到新视图的好时机。 如果需要的话，你可以回滚：甚至放弃商务部，当你放松回到起点。
另一方面，如果您只是为静态信息编写一个查看器，则只需使用一个MOC。 在这种情况下，没有必要或从中获益。
也许关于嵌套托pipe对象上下文的最佳用例存在一些混淆。 对于你的情况，我会build议只使用一个单一的上下文。
从数组移动到核心数据等是一个非常好的主意。 现在释放对象图的真正力量和简单性。 尽量保持简单。
为了深入研究，只需将上下文传递给子视图控制器。 您的子视图控制器提取的结果控制器可以使用与父视图控制器相同的上下文。 许多Apple代码示例正是使用这种模式。
唯一需要上下文的时间是如果你真的需要并发。 这似乎并不是这种情况。 一旦检索到数据，就会显示子视图控制器的新界面。 如果这需要太长的时间（比如说，因为数据来自Web服务），那么您将显示某种“请稍候”的界面，并在数据检索完成后显示完整的界面。 很可能这不是你的情况。