[mikeflynn]

He had me up until the part about models talking directly to views. I was nodding along until then.

While I agree that the application business logic should be in models, but the controller needs to be that traffic cop, only asking for what the view needs and then handing it to the view. Having the view get this giant dump of things from models, skipping the controller entirely makes for confusing code as views can (and should) be reused for multiple data sets on different pages. The controller doesn't have to have much in it, but it's the traffic cop for the page (like a boss).

[Chris_Newton]

The trouble with this article, and indeed many of the posts in this HN discussion, is that what certain web frameworks have decided to call MVC has only a tenuous relationship to real MVC.

The point of MVC, as originally practised in Smalltalk and used by numerous GUI libraries ever since, is the three-way separation of concerns between the underlying data, the presentation of that data, and interactions that change that data. It's an elegant way to reduce dependencies, in particular eliminating dependencies from the model onto any part of the UI, by having some parts of the system push information and others pull it. It remains a useful basic architecture for interactive GUI applications to this day.

In the modern corruption used by various web frameworks, three subsystems have the same names, and that is about where the similarity ends. The three components are typically arranged in a linear stack, with linear dependencies. The responsibilities for the "controller" are very different.

This leads to comments like the parent post:

    He had me up until the part about models talking directly to views.
    I was nodding along until then. While I agree that the application
    business logic should be in models, but the controller needs to be
    that traffic cop, only asking for what the view needs and then
    handing it to the view.

If your view can't present data from your model without going via a controller, then you simply aren't using MVC. Your design might be perfectly reasonable and do its job well, but please call it something else.

[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.