除了从 appDelegate 获取之外，如何获取 viewController 的 managedObjectContext？

Question

最近我开始知道“你真的不应该调用 AppDelegate 来获取托管对象上下文”。 Apple 还将此建议写入其文档here。 它是这样的：

视图控制器通常不应该从全局对象（例如应用程序委托）中检索上下文——这使得应用程序架构变得僵化。视图控制器也不应该为自己的使用创建上下文（除非它是嵌套上下文）。这可能意味着使用控制器的上下文执行的操作没有注册到其他上下文，因此不同的视图控制器对数据有不同的看法。

他们还提到了其他一些获取上下文的方法。到目前为止，我无法弄清楚他们想在那里说什么。任何人都可以对这个问题有所了解。任何代码 sn-p 支持语句都将受到欢迎。

编辑

不过，有时检索 来自应用程序或文档之外的某个地方的上下文，或者 视图控制器。您可能会在基于核心数据的项目中使用的几个对象 应用程序保留对托管对象上下文的引用。托管 对象本身具有对其自身上下文的引用，各种 支持 Core Data 的控制器对象，例如数组和对象 控制器（OS X 中的 NSArrayController 和 NSObjectController，以及 iOS 中的 NSFetchedResultsController)。

从这些对象之一中检索上下文具有优势 如果你重新设计你的应用程序，例如使用 多个上下文，您的代码可能仍然有效。例如， 如果您有一个托管对象，并且您想创建一个新的托管对象 与它相关的对象，您可以向原始对象询问其 托管对象上下文并使用它创建新对象。这会 确保您创建的新对象与 原创。

究竟是什么？确信它与下面高度投票的答案不相似。有人可以帮我理解这部分 Apple 文档吗？

Answer 1

称为依赖注入。基本上，调用者/构造函数应该将NSManagedObjectContext 设置为被调用/构造函数。

在您的AppDelegate 中，您应该将NSManagedObjectContext 设置为与UIWindow 关联的rootViewController。

然后您的rootViewController 应将NSManagedObjectContext 设置为下一个视图控制器，依此类推。

怎么样？它只是视图控制器类的一个简单属性，调用者使用：

[nextViewController setManagedObjectContext:[self managedObjectContext]];

其他人可能会推荐单例，但这是另一个最好避免的深坑。

更新

依赖注入是最好的方法。

这是 Apple 设计的方法。另一种选择涉及某种形式的单例：AppDelegate 或另一种。

“在控制器之间传递相同上下文的缺点是，如果在两个不同的地方修改了相同的实体，则必须管理合并冲突。”

这是一个完全不同的问题，它不会通过多个 NSManagedObjectContext 实例来解决。事实上，多个实例会使情况变得更糟并保证合并冲突。

在这种情况下，您的视图控制器应该监听托管对象的变化并对它们做出反应。使其无法同时在 UI 中的两个位置进行更新。用户根本无法同时关注两个地方，因此第二个位置将实时更新。

这是该问题的正确答案。

将两个实体放在同一上下文中将确保其正常工作。多个上下文将导致它们成为内存中具有相同数据的两个对象，并且如果不保存到上下文，就无法注意到更改。

但是，如果您的视图控制器在没有用户干预的情况下修改数据，那么您将遇到一个单独的问题。视图控制器供用户修改或查看数据。它们不是对任何类型的数据进行后台处理的地方。

如果您处于进口情况，那么这与您提出的问题不同。在这种情况下，您（应该）使用多个线程（UI 线程、导入线程）并且您必须为每个线程至少拥有一个上下文。

在这种情况下，您确实面临合并冲突的风险，您需要针对发生的情况编写代码。第一步是更改 NSManagedObjectContext 实例的合并策略。

更新

我怀疑您误读了该文档。

描述的是从NSManagedObject 实例中获取NSManagedObjectContext 的能力。这绝对有用。以能够添加或编辑对象的视图控制器为例。通过just将NSManagedObject 推送到视图控制器，您可以控制并决定视图控制器将要触摸的内容。接收视图控制器知道它需要允许编辑接收到的NSManagedObject。它不关心它正在使用什么NSManagedObjectContext。它可能与主一起工作，它可能与孩子一起工作，它可能在单元测试中被隔离，它不需要知道或关心。如果用户选择保存编辑，它只显示来自NSManagedObject 的数据并保存关联的NSManagedObjectContext。

该文档并不建议为您的NSManagedObjectContext 提供一些通用位置（又名单身人士）。这表明如果您有其他方法可以访问与NSManagedObject 关联的NSManagedObjectContext，那么这样做是可以的，而且这样做绝对有意义。

Answer 2

在获取托管对象上下文时，单例方法最适合我。这实际上取决于您的应用程序的复杂性，但在我的情况下，我通常会保留一个托管对象上下文，并在需要进行更改时使用临时嵌套上下文。

通过使用基于单例的“DataManager”类，该类包含所有核心数据初始化方法以及对托管对象模型和上下文的公共引用，我可以通过导入我的“DataManager.h”类和调用单例：

// I have a method to create an object that requires the Manage Object Context, so I call it from the DataManager singleton
SomeObject *newObject = [SomeObject createObjectInContext:[[DataManager sharedInstance] managedObjectContext]];

// I have a method in DataManager to save the context
[[DataManager sharedInstance] saveContext];

其实就是简化版。我通常使用嵌套的托管对象上下文，以便在用户确认添加或修改托管对象之前不会修改我的主要托管对象上下文。这种复杂性都可以包含在“DataManager”类中。

这有点离题，但如果您需要了解有关嵌套上下文的更多信息：我在不使用嵌套上下文来更改主托管对象上下文时遇到了严重问题。这篇文章虽然有些超出我的想象，但帮助我理解和实现了嵌套上下文：

http://www.cocoanetics.com/2012/07/multi-context-coredata/