在我的应用中,我UITableViewController
显示了事件列表。此控制器使用ManagedObjectContext Say 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
这是使用Parent - Child上下文的正确方法吗?因为在某个时刻我会喜欢1 NSMainQueueConcurrencyType MOC and 3 NSPrivateQueueConcurrencyType MOC
。
如果不是?还有其他办法吗?
太多的子环境会影响应用程序的性能吗?
最初我使用Properties和NSArrays来管理用户输入的数据,当用户点击完成按钮时,我将更新/创建托管对象。但这是一项繁琐的工作,它使我的视图控制器变脏了。所以我切换到Parent-Child上下文,这很容易保存/丢弃更新。
由于
答案 0 :(得分:4)
你可能对多个子语境有点过分,但只有一点点,你的一般方法是合理的。 MOC(托管对象上下文)是一个相当轻量级的对象。
我喜欢在每个视图控制器/场景中为应用于该场景的MOC提供独特引用的方法。
将MOC视为会话或暂存器有时会有所帮助。匹配不是在MOC和实体之间,而是在MOC和逻辑工作单元之间。
如果您的其中一个下钻标记了某个编辑任务的开始,用户可能想要放弃/取消,那么这是剥离子MOC并将其传递给新视图的好时机。如果需要,您可以回滚:甚至放弃MOC,当您放松回到起点时。
另一方面,如果您只是为静态信息编写查看器,请仅使用一个MOC。在这种情况下,不需要使用更多或从中受益。
答案 1 :(得分:-1)
对于嵌套托管对象上下文的最佳用例,可能存在一些混淆。对于您的情况,我建议只使用一个上下文。
从阵列等转移到核心数据是一个非常好的主意。现在释放对象图的真正力量和简单性。尽量保持简单。
要向下钻取,只需将上下文传递给子视图控制器即可。您的子视图控制器获取结果控制器可以使用与父视图控制器相同的上下文。许多Apple代码示例都使用了这种模式。
你需要上下文的唯一时间是你真的需要并发。这似乎根本就不是这种情况。一旦检索到数据,就会显示子视图控制器的新界面。如果这需要太长时间(例如,因为数据来自Web服务),您会显示某种“请等待”界面,并在数据检索完成后显示完整的界面。很可能这不是你的情景。