我目前正在開發一個win32應用程序，我想我應該使用MVC模式。現在根據該模式，處理用戶交互的代碼應該在控制器中，以便我可以相應地更新模型和/或視圖。 但是在Win32中，這是否意味着我的windowProc應該在控制器中？對我來說這似乎有些奇怪，我會創建一個窗口和所有UI的東西，然後在控制器中對wndProc進行子類化。另一方面，如果我不這樣做，我最終會在視圖中需要一個控制器實例，以便我可以處理該模型。我很確定這不是要走的路。Win32 MVC模式實現
如果任何人都可以指出我正確的方向，那會很棒！
謝謝。
處理用戶交互的代碼是視圖。控制器用視圖「粘合」模型（簡單地說）。窗口過程絕對屬於GUI，即視圖部分。在這個GUI中，您將生成控制器將捕獲的事件，調用模型並對它們做出響應。
MFC的文檔/視圖模型是MVC的一次嘗試。如果您正在考慮使用MFC，那麼您可以使用CView派生類來表示視圖（duh！）和CDocument派生類來表示模型。不幸的是，MFC並沒有真正嘗試將控制器的功能與模型或視圖分開。
在SDI Doc/View應用程序中，Windows GUI的事件驅動特性使得它可以輕鬆地將一些控制器功能放入視圖中 - 並且MFC中的許多向導生成的代碼都可以執行此操作。
在一個MDI應用程序中，每個模型有多個視圖，並且它們中的任何一個都是控制器顯然是錯誤的，所以誘惑是將控制器邏輯放入文檔類或框架窗口中......但添加一個新的類來充當控制器並使用它來包裝域邏輯並不難。儘管如此，把這門課放到MFC中還是有點困難，而且大多數人似乎並不打擾。最簡單的方法是將Document作爲模型和控制器合併爲一個。
這對於MFC（儘管它有許多缺點）仍然是用C++編寫僅限於Windows的GUI應用程序的最高效框架之一。如果你不關心MFC，或者你需要一個可以支持多平臺的框架，你可能已經有了更好的MVC支持 - 例如參見this article關於支持Qt中的MVC。
我沒有使用MFC，我自己在做所有的Win32代碼，所以它確實是一個問題，在哪裏以及如何處理用戶交互代碼。讓視圖中的控制器實例聽起來不可思議，並且在控制器中處理消息似乎也不是要走的路。 – dotminic 2010-10-27 17:27:53
在MVC中，控制器是知道應用程序邏輯的代碼塊;它知道應該如何繪製視圖來表示模型，以及用戶如何與視圖交互來更新模型。當你點擊一個窗口時，視圖類應該得到點擊消息並調用控制器。控制器永遠不應該知道什麼是信息 - 視圖應該將其抽象出來。由於控件（它們是視圖邏輯的一部分）通常包含數據（應該屬於模型），所以Windows使純MVC變得很難。 – dajames 2010-10-27 17:49:58
我真的推薦使用一些框架（無論是MFC，Qt還是wxWidgets，或其他），因爲這需要開發Windows GUI應用程序的大量工作，並且還可以幫助人們思考這些概念，而不會陷入困境在實施細節。在Win32級別工作只會讓生活變得比需要的更艱難。 – dajames 2010-10-27 17:50:55
問題可能是您的抽象程度。假設你有相同的數據模型以及如何修改它的控件，並且你想將整個界面從win32改爲HTML。整個接口位是視圖。
現在，您甚至可以擁有多個模型和控制器，例如域數據，以及當前如何查看應用程序。
控制器通常需要存在於視圖特定部分的生命週期之外。
這就是我想要做的，但我怎樣才能使用win32獲得這種級別的棄權？我知道我需要儘可能多地分離視圖，以便我可以更改爲任何類型的視圖，但這是我遇到的問題。我似乎無法找到一個乾淨的方式來解耦我的視圖和控制器類。 – dotminic 2010-10-27 19:08:15
msdn說：「控制器。控制器解釋來自用戶的鼠標和鍵盤輸入，通知模型和/或視圖根據需要進行更改。」 我所做的是，控制器響應windows消息，然後在UI上調用適當的方法來更新它，但我可能忽略了這一點。 至少我想我正在跟蹤控制器是GUI和數據之間的鏈接。 – dotminic 2010-10-27 17:02:55
MVC模式並沒有嚴格定義。我總是說 - 在設計模式之前使用你的大腦。用戶界面對用戶輸入做出反應，並生成諸如「按下按鈕」或「輸入文本字段中的短語」之類的事件給控制器。 – 2010-10-27 17:19:28
我同意這一點！但那麼我的問題是，如何通知控制器？由於我沒有視圖中的控制器實例，我是否應該實現類似Qt的信號？正如我在下面告訴dajames的時候，我想這樣做是一種「艱難的方式」，所以我知道如果我爲這種實現使用框架，底下會發生什麼。 – dotminic 2010-10-27 18:11:08