責任我有一個菜單面板（文件，編輯，查看等）中的應用程序，我試圖使用模型 - 視圖 - 控制器模式來構建它。控制器菜單面板
它是爲整個菜單創建一個控制器是一個好主意，說MenuController與像FileSaveAs_clicked方法，EditCopy_clicked（與假設我有主工具欄等其他視圖和控制器）或分割在功能方面的控制器責任（ClipBoardController,FileOperationsController等）？如果第二個，那麼如何劃分意見的責任？
也許有人提供有關在大型應用程序模型視圖控制器的實際使用任何好的資源？
謝謝！
我將如何處理這個問題是我會考慮每個可用的命令，而不管我如何在用戶界面中顯示它，然後根據它們在模型上的控制級別或類型對它們進行分組。我的懷疑是，如果你只列出了可以查看模型的每種類型的命令，你會發現你的自然分組。
我不會立足於它們是如何在菜單或工具欄組織了我的決定。無論您的系統是否會受到語音激活，外殼命令，精神控制或其他方面的驅動，如果您不假定它始終使用傳統的桌面GUI呈現，它的設計將會受益。
我可能會安排他們與其他系統（剪貼板，文件系統等）整合的性質，但我不喜歡這種做法一樣多。
換句話說，我的控制器都非常圍繞可能的事情，我可以做的模型沒有考慮視圖在所有設計的，與底層的集成儘可能少的方面。
作爲一個人爲的例子（因爲你不說什麼平臺或系統左右，比它似乎是基於文檔的除外），我可能會列出這些命令爲可用：
它並不真正的問題到底是什麼，這些都還是他們將如何工作，甚至認爲任何事物都有「剪貼板」中的名稱。這些都沒有給我一種組織邊界的感覺。
相反，我會怎麼看待每一個命令可能在上下文中的模型交互。前四個項目可能直接受到我的文檔模型的操作支持，但後兩個項目不太可能作爲文檔模型的操作實現。模型的其他部分（系統模型，領域模型等）將實現這些操作。
所以我可能會有三個控制器。
這是非常粗略的思維;我可能會重新審視並完善這一點。
至於意見，我一點也不確定你的意思是「如何劃分意見」的責任？
該視圖僅具有以特定方式顯示模型的責任，應該完全獨立於控制器的組織。控制者具有視圖的知識（這是「使用」關係）以及準備視圖需要什麼;該視圖不具備控制器的知識。
如果需要更新某個特定的視圖，它可以觀察模型本身，也可以由知道需要更新（或兩者都有）的控制器驅動。無論哪種情況，如果您要重新組織控制器中的命令，則視圖都不應改變。
謝謝，這是一個非常好的答案。特別是最後一句話值得銘記！ 通過編寫「如何劃分視圖的責任」，我的意思是：「如何在課堂上分割視圖」。現在我有一個C＃中的大類，涵蓋了應用程序中的所有控件。我覺得這不是一個好設計。我的第一個想法是把它分成這樣：菜單欄的類，工具欄的類等，但如何將它們與控制器連接？ –
您可以（通常）在其他視圖中嵌套視圖。如果基於實際演示文稿（框架視圖中的工具欄組視圖中的工具欄視圖中的按鈕視圖等）來完成此操作，那麼您的實際平臺將推動您的工作方式。我的回答應該同樣適用於所有平臺 - 網頁，桌面，嵌入式系統。而且您的平臺將推動如何將視圖與控制器相關聯。您可能需要爲此提出一個新問題，具體針對您的平臺。 –
但是，據我瞭解MVC，一個控制器正在處理一個視圖。因此，如果我遵循你的回答並創建'DocumentSelectionController'和'DocumentController'，我不應該在'DocumentSelectionView'和'DocumentView'中保留相關的GUI控件（可能名字不好，但我想顯示與控制器的關係），或者不知何故2控制器應該處理一個視圖？ –