[rickmb]

What you're suggesting is more like MVP (Model View Presenter). Making the view "dumb" in MVC simply results in a lot of overhead and duplicate logic inside the controller, that constantly has to "translate" stuff for the view.

Having the view talk directly to the model actually makes the code a lot simpler (and a lot less of it).

If all your view can get from the model is "a giant dump of things", there is probably something missing from the model. Because in that case, all the controller can get is also "a giant dump", which means you will need to add business logic to the controller to process this giant dump for the convenience of the view. Which puts us right back where we started: bloated controllers that contain business logic that should be in the model.

[mikeflynn]

Ok, fair enough on the "giant dump" statement. That wasn't phrased particularly well. What I was trying to say is that view should be 100% a reusable display, and as such it is given a chunk of data to display, instead of asking for it directly. Not every use case needs the same data, but the display code (say HTML structure for the web) should be able to be reused. Like a list that could be "top users" or could also be used on "top comments" (rough example).

Maybe I'm off and what I'm describing is MVP rather than MVC, but the experience I described is usually the strict interpretation for MVC, whether we're talking about a PHP framework or an iOS app in Objective C.

Edit/Update: ...however, there are times or projects that really need a modification to the "strict definition". For instance, a more modular approach works well at times, and thus you'd have to break some of the MVC/P rules. I did just that at work for a internal PHP framework and it's be a complete success, so obviously I'm not arguing you "shouldn't" or that it's "bad", but the author was discussing what he thought was the traditional definition of MVC, and that's where we disagree slightly in regard to models.

[jasonlotito]

I think there is confusing when you say a view shouldn't have to ask for data. Regardless of how that data is given, at some point, the view has to ask for data. It has to attach itself to some aspect of that data, or it has to print out the data, or whatever depending on the language.

Basically, there is no difference between:

    <?php echo $data['email']; ?>

And

    <?php echo $data->getEmail(); ?>

Both are asking for the email.

Take your list code in HTML example. You can easily create a view that asks for data from a model, and simply ensure that the model always uses the same interface. Now, any model that should be listed has the same interface the view can access.

Views shouldn't be running actions on the model, of course. But it makes no sense to take data from a model, compile it up, and send it over to the view, when you can simply send the model to the view.