views:

56

answers:

3

Hi,

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.

+3  A: 

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.

dark_charlie
the msdn says: "Controller. The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate."What I make of that, is that the controller responds to windows messages and then calls the appropriate methods on the UI to update it, but I'm probably missing the point.Well at least I guess I was on track about the controller being the link between the GUI and the data.
__dominic
The MVC pattern is not really strictly defined. I always say - use your brain before design patterns. The UI reacts on user inputs and generates events like "Go button pressed" or "Phrase in textfield entered" to the controller.
dark_charlie
I agree with that! But then my question is, how to I notify the controller ? Since I don't have an instance of the controller in the view, should I implement something like Qt signals ? As I told dajames below, I would like to do it once the "hard way" so I know what's going on under the hood if I use a framework for this kind of implementation.
__dominic
A lot of MVC implementations basically treat the controller as the input source, and the view as a pure output. So you update the view according to the state of the model, and then the controller receives input from the user and use that to modify the model. And with that design, the window procedure fits perfectly in the controller. It also seems a much cleaner design in that both the view and the controller get much more narrow areas of responsibility.
jalf
A: 

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.

dajames
I'm not using MFC, i'm doing all the Win32 code myself, so it really is a question of where and how to handle the user interaction code. Having the instance of the controller in the view sounds awfull, and having the message handling in the controller doesn't seem to be the way to go either.
__dominic
In MVC the controller is the chunk of code that knows the application logic; it knows how the view should be drawn to represent the model, and how user interaction with the view should update the model. When you click on a window the view class should get the click message and invoke the controller. The controller should never know what a message is -- the view should abstract that away. Windows makes pure MVC hard as controls (which are part of the view logic) often contain data (which should belong to the model).
dajames
I'd really recommend using some framework (be it MFC, Qt, or wxWidgets, or whatever) as this takes a huge amount of work out of developing Windows GUI apps, and also helps one to think about the concepts without getting bogged down in implementation detail. Working at the Win32 level is just making life harder than it needs to be.
dajames
In that case, it means I would need to have a pointer to the controller inside the view right ? I know I'd be better using Qt or something, but I want to do it "by hand", at least this one time to a good understanding of how it all works out.
__dominic
In essence, yes. One way to do it: The application owns an instance of the controller class. The controller has methods to create instances of the document and view classes and passes a reference (or a pointer) to itself as an argument to their constructors. There's a very old (pre-MFC) book called Windows++ by Paul Dilascia that discusses building a simple framework around the win API. Worth a look to get an understanding of the basics, if you can still find a copy.
dajames
A: 

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.

Greg Domjan
That's what I'm trying to do, but how can I get that level of abstration using win32 ? I know I need to decouple the view as much as I can so that I can change to any type of view, but that's what I'm having trouble with. I can't seem to find a clean way to decouple my view and controller classes.
__dominic