我正在构建我的第一个严肃的Cocoa应用程序。它是一个基于文档的应用程序，使用Core Data进行持久存储。使用Xcode“New project”模板选项，我的项目开始时使用了几个默认类：
我从那里接受了设计并且它的工作相当不错，但是通过another question我遇到了一个我不知道的Cocoa类NSDocumentController。该类显然提供了在基于文档的应用程序中管理文档类的默认逻辑。
我的问题是这个课程如何插入我的应用程序 - 如果有的话 - 我是否需要它？此时，我使用EventDocument类作为一种顶级控制器。它从菜单中选择用户选择（带有iTunes选项的树形视图），调出处理这些选项的不同视图/控制器并传递托管对象上下文。如果NSDocumentController是“要走的路”，为什么Apple不将它作为项目模板的一部分生成？
答案 0 :(得分：8)
我相信你误解了NSDocumentController的目标，可能是因为它的名字类似于NSWindowController和NSViewController。
在Cocoa MVC中，控制器调解视图和模型。处理windows时，控制器通常是NSWindowController的子类，在视图的情况下，是NSViewController的子类。
在基于文档的体系结构中，NSDocument类是表示文档的模型与相应的视图和控制器之间的中介。本质上，它负责基于外部表示重新创建模型，并提供一些附加与模型和视图对应的控制器行为的方法。通常使用两种设计：
NSDocument子类有效地充当窗口（可能也是视图）控制器 - 例如，通过实现IBActions。这应该适用于简单的应用程序，但它可以很快导致一个膨胀的NSDocument子类，它处理的应用程序超出了应有的范围。 documentation说：
默认的基于文档的应用程序项目模板不是NSWindowController的子类。如果您正在编写一个简单的应用程序，则不需要子类化NSWindowController。但是，如果您正在编写具有更高级要求的应用程序，那么您几乎肯定会想要这样做。
NSDocument子类创建自定义窗口控制器，后者又实现控制器行为，也可能使用视图控制器。
在许多（大多数？）情况下，不需要NSDocumentController子类 - 应用程序的控制器部分将位于窗口控制器，视图控制器或NSDocument子类中。也就是说，在某些情况下可能需要documentation：
中所述通常，您不需要继承NSDocumentController。几乎任何可以通过子类化完成的事情都可以通过应用程序的委托轻松完成。但是，如果需要，可以继承NSDocumentController。
例如，如果需要自定义“打开”面板，则显然需要NSDocumentController子类。您可以覆盖NSDocumentController方法runModalOpenPanel：forTypes：以自定义面板或添加附件视图。 addDocument：和removeDocument：方法是为想要知道何时打开或关闭文档的子类提供的。