In some circumstances e.g. GUI-based apps it's often acceptable to merge the view and the controller as it doesn't make practical sense to have a separate entity or separate entities to handle callbacks from the UI. As the GUI needs to be able to access the data from the model, it again makes more sense to allow it to do so unhindered hence the merging and blurring of lines between view and controller.

I would describe the "Model" much as you say; the "model" is the data being used to describe the realm of the problem e.g. your collection of classes used to represent concrete objects such as "Square", "Circle" and so on. Your Model may include a top-level class which keeps tabs on the other parts of the model and it may be this top-level class which is presented to the View/Controller bastard child; for example, you may have a load of different objects represented in your model but you have a collection of these in the top-level class, and it's through this collection's methods that you manipulate or use the data.

There will not necessarily be one model for every view; indeed, it's possible to have different views on the same model; remember the definition of the verb "to view" - it's a way of looking at something, whether or not you have a GUI which shows a graph and simultaneously have a terminal showing raw numbers then these are both different views on the same dataset or "model".

I suppose it may be possible to have one view for multiple models, though. I don't see any harm in that, providing there's some kind of convention with regard to data access.

The way I understand it?:

View -> contacts Controller -> Controller contacts Model -> Model does its stuff to fulfil the Controller's request -> data goes back up the way eventually arriving at the View.

I expect I am wrong and am prepared for flaming and a massive rating trough. Hope I've helped anyway, though.

From the examples I've seen, the Controller handles the stateful interaction between the user and the Model, the Model itself is a collection of logic and data, and the View can be seen as windows into the Model from different angles depending upon what you want to see.

The Controllers are intermediary objects between the Model and the user, they can be stateful, ie remember what page your on in a document, have a copy/paste buffer of your selection into the Model, etc.. things like that. For games, the controller could literally be a UI object which captures input from the user ( mouse, keybaord, gamepad, etc ) and keep a buffer of this data and translates it into events which the Model can understand (like mapping the 'w' key to the move_forward event) etc..

The Views are generic output objects which bind to a given Models public interfaces and data. To follow the paradigm of OOP, most of the Model internal implementation is hidden, so the View is only limited to the publicly exposed dataset. For example a text document, the Model could be a text buffer object which exposes text in chunks which can be queried by line, page and character offsets. The View can be a scrolling text window which keep track of the current text line and queries the Model for the displayable text at any given instance. Another equally valid View object could just display the word count of a text document, it doesn't display any text itself, but does act like a view into the document.

For games, common View objects include literally a viewport (3d window) into the scene. The viewport queiries the scene-graph which is itself another view object of the raw Model data ( which is composed of actors, dynamic and static objects and fx objects, etc.. ).

Good Luck!

-ddn