责任我有一个菜单面板（文件，编辑，查看等）中的应用程序，我试图使用模型 - 视图 - 控制器模式来构建它。控制器菜单面板
它是为整个菜单创建一个控制器是一个好主意，说MenuController与像FileSaveAs_clicked方法，EditCopy_clicked（与假设我有主工具栏等其他视图和控制器）或分割在功能方面的控制器责任（ClipBoardController,FileOperationsController等）？如果第二个，那么如何划分意见的责任？
也许有人提供有关在大型应用程序模型视图控制器的实际使用任何好的资源？
谢谢！
我将如何处理这个问题是我会考虑每个可用的命令，而不管我如何在用户界面中显示它，然后根据它们在模型上的控制级别或类型对它们进行分组。我的怀疑是，如果你只列出了可以查看模型的每种类型的命令，你会发现你的自然分组。
我不会立足于它们是如何在菜单或工具栏组织了我的决定。无论您的系统是否会受到语音激活，外壳命令，精神控制或其他方面的驱动，如果您不假定它始终使用传统的桌面GUI呈现，它的设计将会受益。
我可能会安排他们与其他系统（剪贴板，文件系统等）整合的性质，但我不喜欢这种做法一样多。
换句话说，我的控制器都非常围绕可能的事情，我可以做的模型没有考虑视图在所有设计的，与底层的集成尽可能少的方面。
作为一个人为的例子（因为你不说什么平台或系统左右，比它似乎是基于文档的除外），我可能会列出这些命令为可用：
它并不真正的问题到底是什么，这些都还是他们将如何工作，甚至认为任何事物都有“剪贴板”中的名称。这些都没有给我一种组织边界的感觉。
相反，我会怎么看待每一个命令可能在上下文中的模型交互。前四个项目可能直接受到我的文档模型的操作支持，但后两个项目不太可能作为文档模型的操作实现。模型的其他部分（系统模型，领域模型等）将实现这些操作。
所以我可能会有三个控制器。
这是非常粗略的思维;我可能会重新审视并完善这一点。
至于意见，我一点也不确定你的意思是“如何划分意见”的责任？
该视图仅具有以特定方式显示模型的责任，应该完全独立于控制器的组织。控制者具有视图的知识（这是“使用”关系）以及准备视图需要什么;该视图不具备控制器的知识。
如果需要更新某个特定的视图，它可以观察模型本身，也可以由知道需要更新（或两者都有）的控制器驱动。无论哪种情况，如果您要重新组织控制器中的命令，则视图都不应改变。
谢谢，这是一个非常好的答案。特别是最后一句话值得铭记！ 通过编写“如何划分视图的责任”，我的意思是：“如何在课堂上分割视图”。现在我有一个C＃中的大类，涵盖了应用程序中的所有控件。我觉得这不是一个好设计。我的第一个想法是把它分成这样：菜单栏的类，工具栏的类等，但如何将它们与控制器连接？ –
您可以（通常）在其他视图中嵌套视图。如果基于实际演示文稿（框架视图中的工具栏组视图中的工具栏视图中的按钮视图等）来完成此操作，那么您的实际平台将推动您的工作方式。我的回答应该同样适用于所有平台 - 网页，桌面，嵌入式系统。而且您的平台将推动如何将视图与控制器相关联。您可能需要为此提出一个新问题，具体针对您的平台。 –
但是，据我了解MVC，一个控制器正在处理一个视图。因此，如果我遵循你的回答并创建'DocumentSelectionController'和'DocumentController'，我不应该在'DocumentSelectionView'和'DocumentView'中保留相关的GUI控件（可能名字不好，但我想显示与控制器的关系），或者不知何故2控制器应该处理一个视图？ –