Win32 MVC 模式实现
我目前正在开发 win32 应用程序，我想我应该使用 MVC 模式。现在根据模式，处理用户交互的代码应该位于控制器中，以便我可以相应地更新模型和/或视图。 但在 Win32 中，这是否意味着我的 windowProc 应该位于控制器中？这对我来说似乎有点奇怪，我会创建一个窗口和所有 UI 内容，然后在控制器中对 wndProc 进行子类化。 另一方面，如果我不这样做，我最终将需要视图中的控制器实例，以便我可以处理模型。我很确定这不是正确的方法。
如果有人能指出我正确的方向，那就太好了！
谢谢。
I'm currently working on a win32 application and I'm thinking I should probably use the MVC pattern. Now according to the pattern, the code that handles user interaction should be in the controller so that I can update the model and/or view accordingly.
But in Win32, would that mean that my windowProc should be in the controller ? It seems a little strange to me, I would create a window and all the UI stuff, and then subclass the wndProc over in the controller.
On the other hand, if I don't do that, I would end up needing an instance of the controller in the view so that I can handle the model. I'm pretty sure that's NOT the way to go.
If anyone could point me in the right direction, that would be great!
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
处理用户交互的代码是视图。控制器将模型与视图“粘合”在一起（简单地说）。窗口过程肯定属于GUI，即视图部分。从这个 GUI，您将生成控制器将捕获、调用模型并响应它们的事件。
The code that handles user interaction is view. Controller "glues" the model with the view (simply said). The window procedure definitely belongs to the GUI, i.e. the view part. From this GUI you will generate events that the controller will catch, call model and respond to them.
MFC 的文档/视图模型是对 MVC 的不成熟尝试。如果您正在考虑使用 MFC，那么您可以使用 CView 派生类来表示视图（废话！），并使用 CDocument 派生类来表示模型。不幸的是，MFC 并没有真正尝试将控制器功能与模型或视图分开。
在 SDI Doc/View 应用程序中，Windows GUI 的事件驱动特性使得将某些控制器功能放入视图中变得非常容易，而且 MFC 中向导生成的大部分代码都可以做到这一点。
在 MDI 应用程序中，每个模型有多个视图，并且将其中任何一个视图作为控制器显然是错误的，因此人们倾向于将控制器逻辑放入文档类或框架窗口中......但事实并非如此很难添加一个新类来充当控制器并使用它来包装域逻辑。不过，将该类引入 MFC 有点困难，而且大多数人似乎并不介意。最简单的方法就是将文档视为模型和控制器合二为一。
这对于 MFC 来说（尽管它有很多缺点）仍然是用 C++ 编写仅限 Windows 的 GUI 应用程序的最高效的框架之一。如果你不关心 MFC，或者你需要一个可以支持多个平台的框架，你可能已经有了更好的 MVC 支持——参见 这篇文章。
MFC's Document/View model is a half-baked attempt at MVC. If you're thinking of using MFC then you can use a CView-derived class to represent the view (duh!) and a CDocument-derived class to represent the model. Unfortunately MFC doesn't really try to keep the controller functionality separate from the model or the view.
In an SDI Doc/View application the event-driven nature of the Windows GUI makes it seductively easy to put some of the controller functionality into the view -- and much of the Wizard-generated code in MFC does this.
In an MDI application there are multiple views per model and it is obviously wrong for any one of them to be the controller so the temptation is to put the controller logic into the document class or into the frame window ... but it isn't hard to add a new class to act as controller and use it to wrap put the domain logic. Plumbing that class into MFC is a bit of a struggle, though, and most people don't seem to bother. The easiest approach is simply to regard the Document as model and controller rolled into one.
That's for MFC (which, despite its many shortcomings) is still one of the most productive frameworks for writing windows-only GUI apps in C++. If you don't care for MFC, or if you need a framework that can support multiple platforms, you may already have better MVC support -- see this article on supporting MVC in Qt, for example.
问题可能在于你的抽象程度。
假设您有相同的数据模型以及如何修改它的控件，并且您想要将整个界面从 win32 更改为 HTML。整个界面就是视图。
现在，您甚至可能有多个模型和控制器，例如域数据以及应用程序当前的查看方式。
控制器通常需要存在于视图特定部分的生命周期之外。
The problem is perhaps your level of abstraction.
Say you had the same data model, and the controls of how to modify it, and you wanted to change the whole interface from win32 to HTML. That whole interface bit is the view.
Now you may even have multiple models and controllers, say for the domain data, and for how the app is currently viewed.
The controllers often need to exist outside of the lifetime of a particular part of the view.