我目前正在开发一个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