CODEWITHSUNDEEP
c++model-view-controllerdesign-patternswinapi
dotminic
dotminic

Reputation: 1145

Win32 MVC pattern implementation

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.

Upvotes: 4

Views: 3271

Answers (3)

Greg Domjan
Greg Domjan

Reputation: 14115

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.

Upvotes: 0

dajames
dajames

Reputation: 2916

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.

Upvotes: 1

Karel Petranek
Karel Petranek

Reputation: 15164

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.

Upvotes: 3

Related Questions