Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm conceptually trying to understand if I should be doing this:

item = Model()
screen = View()
brain = Controller(item, screen)

or this..

brain = Controller()
item = Model(brain)
screen = View(brain)

or this..

class Controller():
    def __init__(self):
        item = Model(self)
        screen = View(self)

or something else entirely?

share|improve this question

5 Answers 5

up vote 11 down vote accepted

To me, the first option makes sense. The job of the Controller is to co-ordinate between the view and the model. From that point of view, it makes sense for the controller to be the one that controls references to the view and model.

You can't really have a controller without a Model and a View, however it makes a lot more sense to just have a View or just have a Model (for example, in unit testing). That's why you want to pass in those dependencies into the Controller, and not the other two.

share|improve this answer

MVC is more like a modularity pattern. Its purpose is that whenever you want to change the user interface layout (view), you don't have to change de application logic (controller) or the internal data processings (model).

In order to acheive this, the pattern is to isolate the implementation logic of each MVC components. Still, it's perfectly normal that there components know each others interfaces.

What I often saw is that the controler create or call model and view (thus it knows their interface) and model or view can notify the controler in return (more like a callback, or observer pattern). The important part is that the controler is not aware of layout structure.

share|improve this answer

The view should subscribe to changes in the model. There is latitude in the richness of subscriptions as they may be detailed (show me inventory changes for this particular item) or generic (the model has changed); the view may query the model in response to change notification. The view presents its desired set of model elements on the screen, updating the screen as when handling change notifications.

The controller should push changes to the model, as a result of user direction (e.g. keyboard in put, mouse & menu commands).

The model maintain the model and a list of subscriptions, and should notify views of applicable changes via their subscriptions.

There also needs to be a mechanism to create new views and controllers (since in MVC you should be able to have two or more views of the same model (they could be the same view(point) or different view(point)s). Logically, we can consider that the controller needs to perform or have access to a view & controller (pair) factory, which can be part of the controller or another component.

share|improve this answer
    
-1 Models do not notify Views. Controllers query the Model for changes, and then render Views to present those changes. –  Mathew Foscarini Feb 3 '13 at 5:16
2  
@MathewFoscarini in MVC, the View subscribes to changes from the Model. See, for example, wiki.squeak.org/squeak/598. –  user4051 Feb 3 '13 at 18:02
    
I think we're not talking differences in an existing MVC frameworks. Zend MVC, C#.NET and CakePHP don't connect a Model to the View. A View in those frameworks is independent. I don't know what MVC you've worked with, but I'd call it non-traditional. –  Mathew Foscarini Feb 3 '13 at 18:27
4  
@MathewFoscarini: those are all web frameworks, and even though they call themselves "MVC", they are not following the classic MVC architecture. –  kevin cline Feb 4 '13 at 5:02
    
Trying to understand MVC, I came across a similar discussion about this topic here. It seems there is/was such a thing as a 'passive' model where the View talks directly to the Model. –  alnafie Feb 4 '13 at 6:52

The Model and View are independent of each other.

Don't think of the Controller as the brains of the MVC structure. Think of it as the dispatcher which handles the requests from the browser, and dispatches them to the Model. It then takes the data from the Model and packages it in a template friendly way, and then sends it to a View.

The Model is the brains in the MVC structure, and this is where you should put your business rules. Business rules are common across multiple controllers. So a document controller, and a reports controller may both use a User model to see who has access to those things. You wouldn't want to repeat those rules in both controllers.

The View should use a HTML template to present the data in a non-datasource specific way. It should not be tightly bound to the schema of your database. To show the title of a document you would have the view output the contents of a template variable called document_title, and only the Controller knows how that variable was set, and only the Model knows why that document has that title.

share|improve this answer
1  
I like your answer as it gels with my overall understanding of MVC. However, it doesn't address an important part of the question, specifically which parts of the Triad hold references to the others? The confusion I think stems from the fact that what you describe, is that Views are "dumb templates with holes" (ie. hold no reference to the Controller, but the Controller knows the Views and plugs data from the Model into them). At the same time, another common thing I keep seeing is that Views should send user actions to the Controller. How could Views do this without having a reference to C? –  alnafie Feb 3 '13 at 11:12
    
@alnafie You have over simplified the a MVC framework into just 3 classes. Take look around at existing MVC open source frameworks, and you will find there is a lot more required to make it work. There has to be something higher that manages all the pieces for the framework. Something that calls the Controllers, and something that handles routing to actions in the Views. –  Mathew Foscarini Feb 3 '13 at 18:24

MVC was originally defined to ease the programming of desktop applications. The view subscribed to model events, updating the presentation when the model changed. The controller merely translated user interface events (e.g. a button press) into calls to the model. So the controller and view depended on the model, but were independent of each other. The model was independent of both. This allowed multiple views and controllers to work on the same model.

The "MVC" architecture used for web 1.0 applications (full page refresh, no AJAX) is somewhat different. A web request is dispatched to a controller. The controller somehow modifies the model state, then sends one or more models to be rendered by a view. The controller and view both depend on the model, but the controller also depends on the view.

With web 2.0 applications, we are returning to the classic MVC architecture, on the client side. The model, view, and controller all reside on the client side as Javascript objects. The controller translates user events to model actions. The model actions may or may not result in an AJAX request to the server. Again, the view subscribes to model events and updates the presentation accordingly.

share|improve this answer
    
+1 good answer. I can understand model callbacks for desktop applications in the classic sense. Reminds me of old MFC from Microsoft. –  Mathew Foscarini Feb 4 '13 at 7:08

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.