当我在应用程序的许多领域工作时，标题问题出现了：模型，控制器，getter，setter，actions等。我有一个基于Core Data文档的应用程序，我不断需要获得当前的参考NSMangedObjectContext对象。
当前场景涉及我为处理“模拟”而设计的自定义控制器（此应用程序模拟特定类型的数学模型。）有一个名为“模拟”的按钮，它被绑定到模拟控制器中的一个动作。模拟控制器需要从当前文档获取信息，即来自当前管理对象上下文中的NSManagedObjects的信息。
模拟控制器是NSObjectController的子类，它有一个名为managedObjectContext的方法，但是当我调用该方法时，我得到了nil。我不确定为什么返回nil，但我知道控制器不代表任何托管对象。它控制着模拟器，它不是MVC中的模型。控制器是视图，模型和模拟器之间的接口。
如何获取为当前打开的窗口存储NSManagedObjects的NSManagedObjectContext？当前打开的窗口具有显示上下文中对象信息的视图，模拟按钮位于此窗口的工具栏中。
嗯...感谢TechZen让我开心一点......或许它只是休息一下去烧烤......
对于这种特殊情况，答案是：
将Interface Builder中的托管对象上下文绑定到我的控制器（控制器是在界面生成器中创建的，然后我将类更改为我的NSObjectController的子类）。此设置可在“参数”下的“绑定检查器”中找到，称为“托管对象上下文”。我将其设置为绑定到文件的所有者和模型密钥路径“managedObjectContext”。
然后，消息“managedObjectContext”在我的控制器中工作，如：
[self managedObjectContext];
然而，这仍然没有完全回答我的问题，因为我还想在NSManagedObject的子类的类方法中获得对托管对象上下文的引用。因此，如果模拟控制器然后通过在我的NSManagedObject的子类上调用类方法来创建新的NSManagedObject，我希望该方法具有对上下文的引用并创建对象。而且我不想将上下文传递给方法...我觉得类方法应该能够获取上下文...我记得看过如下代码：
[[NSApp delegate] managedObjectContext];
但这对我不起作用。但如果确实如此，这将是一个很好的解决方案，因为NSApp是全局的并且返回当前的NSApplication实例。
好吧，经过大量的阅读和谷歌搜索......我发现在我的应用程序设计中我完全不合适。我没有让模拟控制器接收模拟按钮的点击，而是为该窗口创建了一个自定义的NSWindowController，它接收模拟按钮点击事件（一种IBAction）。 NSWindowControllers引用了NSPersistantDocument，它引用了NSManagedObjectContext。我编写的这个自定义窗口控制器得到了NSManagedObjectContext并将其传递给模拟控制器......世界充满喜悦。不确定这对其他人有多大用处，因为这个问题和答案现在充满了噪音。
答案 0 :(得分：3)
如果您使用的是基于Core Data文档的应用程序，那么每个文档都将是NSPersistentDocument的一个实例，该实例将为该单个文档提供自己的NSManagedObjectContext。
您可以通过以下方式获取上下文：
NSManagedObjectContext *context=[aPersistentDocument managedObjectContext];
使用基于文档的应用程序，您没有单个，中央或主要托管对象上下文，因为每个文档都有自己的完全独立的Core Data堆栈，从商店到上下文。你最终拥有了许多开放文档的上下文。
与更像数据库的设计形成对比，其中整个应用程序仅具有在编写应用程序时定义的那些存储和上下文。在这种情况下，您可能只有一个在应用程序中随处使用的上下文。在这种情况下，您可以将上下文停放在应用程序委托中，并从任何位置访问它。
在NSManagedObject子类中找到一个类或实例方法找到一个上下文是不好的设计，因为这限制了子类使用的灵活性。为此，必须将类连接到特定应用程序的结构中，以便子类只能在可以找到上下文的特定设计中使用。如果您更改了上下文的位置或使用子类，则必须重新编写它。
我认为您需要退出并重新考虑您的设计，并决定是否需要基于文档的应用或更像数据库的应用。我建议阅读：
Document-Based Applications Overview和NSPersistentDocument Core Data Tutorial