核心数据多级父-子上下文

在我的应用程序中我有UITableViewController显示事件列表。该控制器使用 ManagedObjectContext 说ParentContext。现在，如果选择任何事件，则会显示详细的视图控制器，用户可以在其中编辑事件的详细信息。所以我创建了一个子上下文，

ChildContext with type "NSPrivateQueueConcurrencyType"

ChildContext whose parent Context is "ParentContext".

我的代码是：

  NSManagedObjectContext *childContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
  childContext.parentContext = self.context ;

现在，有些字段和关系再次需要深入研究。所以我为新视图控制器创建了另一个 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.

如果不是？还有其他办法吗？

过多的子上下文是否会影响应用程序的性能？

最初我使用 Properties 和 NSArrays 来管理用户输入的数据，当用户点击完成按钮时，我将更新/创建托管对象。但这是一项乏味的工作，它使我的视图控制器变脏。所以我切换到父子上下文，这很容易保存/丢弃更新。

Thanks

您可能对多个子上下文有点过分，但只有一点点，而且您的总体方法是合理的。 MOC（托管对象上下文）是一个相当轻量级的对象。

我喜欢你的方法，在每个视图控制器/场景中，对适用于该场景的 MOC 有一个独特的参考。

有时将 MOC 视为会话或草稿本会很有帮助。匹配不是在 MOC 和实体之间，而是在 MOC 和逻辑工作单元之间。

如果您的某个向下钻取标记了用户可能想要放弃/取消的某些编辑任务的开始，那么这是分离子 MOC 并将其传递到新视图的好时机。如果需要，您可以回滚：或者甚至放弃 MOC，当您放松回到起点时。

另一方面，如果您只是编写静态信息查看器，则仅使用一个 MOC。在这种情况下，就没有必要使用更多，也没有必要从使用更多中受益。