   I don't understand MVC!
  I've read a lot about MVC; I really have. That being said, I really feel as though I barely understand it!Here is what I [think that I] know:Model: The models are the "physical" objects – users, forum posts, shopping carts, ect. – and contain the business logic needed to manipulate them.View: The views are what are presented to the user (in the case of web design, they'll usually contain html). Views contain no business logic; they are pure presentation. They fetch their data from their respective models.Controller: The controller has two main tasks: it determines which view to use, and if the user is altering a model, which model's method to call.Am I on track so far? Some websites say that controllers (note the plural) should have all the business logic, though that doesn't make any sense to me.Many websites make it seem like every there will be one model for every view, which is fantastically unrealistic; some pages will need to use more than one model! Am I supposed to create a model for every page (like UserThreadTopic)? That seems silly.I'm sorry for the rambling post, but I don't know how else to word it.[Edited by - iaminternets on June 20, 2009 10:23:28 PM]
  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;  Before I start: I speak out of the depth of my ignorance, and have only my experience and thoughts to guide me. I'm mostly just trying to refine the question.It seems that there are two possibilities for the role of the Controller. It can either take user input and pass it to the Model, which has all the actual "business logic" (which may also be update logic in the case of a game), or it can contain the "business logic" and use it to operate on the model. In the latter case, user input would come from some other part of the application.I have no idea which of these is technically MVC. My understanding is that MVC proper is a more specific pattern than just the general idea of separating the Model, View and Controller, that it's a technical term to describe a specific design pattern, if I may hijack that term for a moment.I would also be grateful if someone cleared that up.My advice right now is to not get too hung up on the specific details of everyone else's MVC. Just look at them, learn from them, and take the parts that make sense and use them. If worse comes to worst, you'll get it wrong and have to change it. Just don't use that as an excuse to not understand things. Give everything your best shot to understand it and learn from it, and then do what makes sense. The best solution is almost always some balanced combination of various ideas.   