MVC: Model View Controller — does the View call th

Question

I've been reading about MVC design for a while now and it seems officially the View calls objects and methods in the Model, builds and outputs a view.

I think this is mainly wrong.

The Controller should act and retrieve/update objects inside the Model, select an appropriate View and pass the information to it so it may display. Only crude and rudiementary PHP variables/simple if statements should appear inside the View.

If the View gets the information it needs to display from the Model, surely there will be a lot of PHP inside the View -- completely violating the point of seperating presentation logic.

Answer 1

MVC is not a law set in stone. Depending on where you read about it it can differ. Personally I don't allow the View to read directly from the Model.

Update This post has some good examples as well. The model is the engine of the car with start() like methods, the view is the color of the car with paint() or change() methods and the controller is the driver. I prefer to let the controller drive() the car and start() the engine instead of letting the wheels or the paint doing it.

:)

Answer 2

It's probably not what one would call "pure" MVC, but IMHO it's not a huge deal as long as the view PHP code doesn't mutate the model. The most important rule of MVC is that the model doesn't know about the view. Having the view not know about the model is less important.

The main downside to using the model directly is that the view can't be reused with a different model. This is rarely a problem, because the view is almost always specific to one particular type of model object (or a list thereof).

Answer 3

MVC refers to layers, not components. So they are more abstract concepts, than a blueprints. Since it's not really possible to separate the layers entirely (Information has to flow between them), it's really a continuum where you have spaghetti on one extreme and bureaucratic type systems on the other. You probably want to find somewhere in between those two.

I generally don't spend too much effort on the controller-view separation. The separation between model and (controller-view) is much more important.

Answer 4

There isn't one absolute and correct way to do MVC. Variations are possible.

For example, instead of having the View actively querying the Model, the Controller can notify the view of any changes in the Model, using some sort of notification mechanism. In that case, the View is just listening for updates, which are then being presented.

Answer 5

Would the following modifications to DisgruntledGoat's code snippet be considered too "complex"? Should objects be passed to the view?

<li><?=$item->description?></li>

Or maybe?

<li><?=$item->getDescription()?></li>

I've seen several examples where only arrays are used:-

<li><?=$item['description']?></li>

Answer 6

I think you are absolutely correct - Views shouldn't call methods from the Models. Like others said, there are variations on MVC but the point it to separate logic from data from output.

So generally, you have a controller which is the start point for the application. In PHP, this would be your index.php file. At a minimum this file would process the input data (i.e. the query string or URL parameters). It's usually a good idea to add separate controllers for separate parts of the app.

Each controller then simply decides what data needs to be displayed, gets it from the model, and passes it to the view. In PHP, you would call various classes/methods that fetch data from the database, storing it in variables.

Then you simply include another PHP file containing mostly HTML, but with some PHP echoing variables. Loops are fine, too. If you have a list of things, you may want to do something like this:

<ul>
<?php foreach ($items as $item) : ?>
  <li><?=$item?></li>
<?php endforeach; ?>
</ul>