views:

96

answers:

4

i know that everything is going through the controller.

but i often read articles that says something like this:

  1. user interacts with the view
  2. controller asks the model to change its state
  3. model notifies the view when its sate has changed

i dont get the 3rd one. why saying that the model notifies the view, when it actually is notifying the controller and the controller is notifying the view?

+4  A: 

That seems more like a desktop system and not a stateless system like a website.

But maybe it's talking about how some people like to query the models from the view e.g.

<?php foreach( $usersTableGateway->getUsers() as $user ): ?>
<?php echo $user ?><br>
<?php endforeach; ?>

I'm more of a fan of getting all the info in the controller (preparing the users array in the controller) and passing it to the view from the controller.

Galen
+1 agree with this. It is better to do something like this in the controller `$template->set('users', $usersTableGateway->getUsers());`
alex
+1  A: 

I have indeed occasionally seen MVC described this way or drawn this way. I wouldn't say this is correct, but I think it arises from many implementations that either explicitly or implicitly lump the controller and the model together.

If the framework's conceptual separation between the controller and model aren't as clear as they ought to be, then the part about the "model notifies the view when its state has changed" is really a controller bit that happens to be in the model.

In the end, MVC is a guideline that mostly depends on clear separation of concerns. If the framework you're using describes things that way... well, it's not really MVC. It might work, but it might also fail in ways that are unexpected or even undetected.

stw_dev
+1  A: 

MVC is a broad concept, and there are a wide variety of possible implementations. For example, Page Controller separates logic from the view, and so does Front Fontroller. Each MVC framework also has different methods for rendering model data in the view - Zend uses Two-Step for example.

You could possibly set up an Observer relationship between a view object and "the Model" (which in itself is a really complicated beast) but I think this aspect of the MVC pattern is more to do with the original context of the pattern - i.e. Galen's point above

sunwukung
A: 

It doesn't violate MVC principles to have your View listen directly to your Model ( See here ). ASAIK the one rock-solid rule of MVC is really that you have a fat, blind Model, which guards data and business logic and is unaware of other parts of the system. How the Views and Controllers are delineated, and their relationship with the model, is less rigorously defined.

Yarin