我有一个非基于文档的Core Data应用程序。有NSTreeController管理单个NSOutlineView中显示的对象集合作为源列表。它们是常见的东西：标题，文件夹，智能文件夹等。
每个容器对象都有一个contents个对象的集合。我有三个独立的视图控制器，以各种方式显示这些对象（NSTableView和两个自定义图形视图，如果你真的想知道）但这些实际上只是相同数据的三个不同的表示。它们应始终显示相同的对象，共享相同的选择等。
我还使用NSViewController的层次结构来管理我的观点。 （如果我当时知道Cathy Shive的优秀KTUIKit，我会使用它，但我的视图控制器非常类似于 - 并且非常受她的启发）
现在看来，我有一个NSTreeController生活在视图控制器中，用于源列表视图。我在每个子视图控制器中都有一个NSArrayController，它通过一些过于复杂的键路径绑定到NSTreeController。
所以，在我看来，需要改变的是：
NSTreeController需要移出大纲视图的控制器。NSArrayController而不是三个独立的视图。虽然我不太确定这一点。我遇到的困难是找出 这些东西应该存在的地方。我很难决定哪些对象（如果有的话）真正“拥有”各种控制器。父视图控制器是否拥有它？窗户控制器？由于这是应用程序级数据，我是否应该让App Delegate拥有这些数据？ （我可以想象一个用户可能想要打开多个窗口的情况，虽然目前不支持）StackOverflow蜂巢思维的想法是什么？
答案 0 :(得分：2)
NSArrayController和NSTreeController被视为视图对象而不是真正的控制器，因此听起来就像是在正确的轨道上。我会以与你相同的方式开始，根据需要为每个NSViewController提供自己的NSArrayController或NSTreeController，并在运行时通过负责将所有部分放在一起的窗口控制器配置它们之间的绑定。
如果您认为它会简化操作，那么将NSArrayController和NSTreeController对象移动到窗口控制器听起来并不会有任何问题。您仍然可以在IB中设置绑定到视图控制器的representObject，然后在适当的时候在窗口控制器中的代码中创建数组/树控制器。请小心谨慎，不要太复杂。我发现当你在同一窗口中有很多视图控制器使用表示对象来处理不同的东西时，创建单独的类型属性会更容易，这样你就可以理解哪些部分去了哪里。
我真的不明白使数组/树控制器成为app委托的一部分的好处，但我不太了解你在那里做什么。也许你会从制作自己的“数据控制器”对象中受益？
这样的问题很难决定，因为有时候没有“正确”的答案，但只要你保持简单和可理解性，你就可以了。不要害怕选择计划并继续前进，你可以随时重构...我知道有时候我花了几天时间讨论这样的架构问题，当时我可以做更实际的事情！