ios - 核心数据 - 管理上下文

Question

我希望你们对我写的所有内容发表评论，因为我想知道我是否走在正确的轨道上。所以，就在这里。

当您的应用程序具有多个执行不同任务的 View Controller 时，您会说使用多个托管对象上下文是正确的方法吗？我发现在 View Controller 中拥有单例上下文和子上下文可以解决当您只想保存部分上下文时的问题，即创建小的本地上下文并在将所有内容保存到存储之前将所有内容推送到主上下文中。 例如，我使用一个现在属于上下文的 VC 创建了一些对象，但我没有按保存新对象。但后来，有了新对象，我去了其他 VC 并保存了其他东西。问题是，作为同一上下文的一部分，您保存了整个上下文状态。在这种情况下，我似乎必须分离上下文。

我认为使用上下文层次结构会将在一个上下文上所做的更改传播到父级，然后其他子级在再次获取时会看到编辑过的数据，但事实并非如此。如果我想查看更改，我必须使用 refreshObject:mergeChanges:与 YES作为参数。另外，我必须再次获取以检查新记录。有更好的解决方案吗？ 比如我根据我的设置加载VC，到其他VC，修改设置保存。现在，当我回来时，我想在 viewWillAppear: 中根据设置中所做的更改来获取更改和更改 GUI。但是，问题是当我获取设置时，我得到相同的数据，我认为是因为缓存？但是在这种情况下，父上下文有什么意义呢？

那么，如果您必须一直获取和刷新，是否真的需要多个上下文？ 与上面类似，如果它们不传播更改，为什么要链接上下文？

重置上下文 - 什么时候是重置上下文的好时机？如果我使用单例上下文，所有内容都存储在其中，所以一段时间后，它可能会使用大量内存，对吧？那么，从这个角度来看，我真的想在上下文中使用单例吗？ 例如，我有一个我在某些 tableView 中呈现的对象列表。由于在层次结构中我一直持有它，因为它是导航堆栈的一部分，我应该一直持有所有对象，还是在我到达那个 VC 时处理它们并再次获取它们？我的意思是，如果对象属于不同的上下文，我不能对它们做很多事情。我必须通过它们的 ID 获取对象才能将它们与未连接的上下文一起使用，对吗？

Answer 1

所以我不是 CoreData 专家，但我会尝试解决每一个问题。您应该阅读这篇精彩的 article在核心数据上，即让其传播更改的父子上下文。

1)我认为在进行过程中保存上下文是一种常见的做法 - 您想要更改一个 VC 上的数据、转到下一个、更改更多数据并保存它的用例是什么，但忽略前一个 VC 上的数据?如果您打算简单地放弃更改，那么 [managedObjectContext rollback]应该是您要求取消以重置上下文状态的方法。

2)我假设您已按照文章中的描述将您的 VC 设置为父子层次结构 - 如果是这样，请确保您保存了子节点和父节点的上下文。子进程将更改推送到父进程，然后保存父进程实际上将更改保存在 coredata 中。在 viewWillAppear 上，当您轮询 CoreData 时，应该会出现更改。

3)请参阅上面链接的很棒的文章以保存子上下文和父上下文:)

4)我不必为了释放内存而重置上下文。一般来说，从我所看到的情况来看，人们确实使用了在 appload 上实例化的单例(然后是父子在后台更新数据)。 SO 中的一位大人物可能可以更好地描述内存发生的情况，但如果您真的担心，您可以在 ViewDidDisappear 上取消 VC 的指向单例的上下文指针。 ，然后在 viewWillAppear 上重新实例化它重新加载对象。