I've been reading everything I can on the topic, because MVC, or at least, some seperation of concerns, seems like a great idea. I think most of us have written GUI code that was horribly, inextricably bound up with the underlying domain model.

However, as others have noted on ModelViewController, it seems extremely difficult to find a simple, clear, grokable explanation of how this thing might actually work. So, I'll try figure this out by relating some actual code I've been writing. Hopefully all will become ClearAsMud in short order :)

Problem: I want to display some visual objects to the user, and let them drag them around, modify them, whatever. Most of this happens with the mouse, like in a vector-based drawing tool.

So, I define some simple domain classes, one for each kind of thing I want to represent. They share some common protocol, so I factor that out into a common base. I figure this set of classes is what we're referring to as the 'Model'.

Now, I need to display this stuff to the user, so I whip up some quick & dirty rendering code (in .NET, it really is quick, and it sure is dirty.) I try not to tangle it up with the model classes. A bit more refactoring later, and I get specialized renderers for each kind of object I can draw on my design surface. They share some common protocol, too, and that is factored out. Turns out that the 'draw' method is in the common stuff, so I dont need the object that coordinates the drawing to know what's going on inside.

This sounds like 'view', unless I'm horribly mistaken.

Now I need a way to interact with these things. The first interaction I want is to be able to move objects around by dragging them. I've done this a bunch of times before, and it involves responding to mousedown/mousemove/mouseup messages on the window that the objects are drawn on. Initially, this goes in an event handler hanging off the window. Again, quick, dirty, make-it-work code.

Now I want to be able to resize things by grabbing 'handles' around their edges and dragging. My first attempt involves a whole pile of magic on top of the object movement code, checking if the mouse is in a certain part of the screen, and if so, doing that instead. However, the input handling is getting pretty unweildy by now.. its a couple hundred lines in an event handler, and not all of it is obvious. Also, I seem to be duplicating a lot of the layout logic in the input handling, and not making the world amazingly fast.

I get the idea of creating 'manipulators', as small, visual objects, which do their own mouse handling, and make their own changes to the model. For now, when I refresh the view, I clear out the list of manipulators, and then as I render each object, create manipulators for its various parts. This isnt fast, but all the dodgy mouse handling math disappears.

I figure these objects, along with the logic to get events to them, might be something like the 'controller' part of MVC. 

Let me know what you think, and in particular, if I've missed the boat on some point.

--