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.
Comments
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:
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.