Hacker News Reader

Comment by Periodic | Hacker News Reader

In terms of pure code, the view returns data, which the controller then can route to the appropriate place to show. In this case the view generates an HTML response, but it could also generate an audio response or a video response.

I understand that from an OO stand point it makes a lot of sense for the view to directly control that, but in a functional world it makes more sense for the view to pass back something which the controller then routes to the user, making it more of a formatting layer than a display layer.

So yes, a functional MVC and OO MVC may have very different meanings.

View on HN

Huh? In the world I grew up in, the controller is the middleman sitting between the model (the raw data representation or, at the highest level, the ORM) and the view (the "client", if you will). The controller is where the application logic lives. In a web app, the view is the HTML chain (it requires the web server, the browser and the HTML/JS/CSS to be complete) and the controller is just about everything that sits between the database and the HTML page. Complete separation of the view and controller can only really happen with a templating system (or with a page that essentially self-assembles in the browser using AJAX/AJAJ).

This is a fascinating discussion, because I don't think either of the architectures described in the parent and grandparent posts is even close to MVC.

Views returning data that controllers then show? Controllers containing application logic?! To me, it seems these things are almost the opposite of what MVC is supposed to achieve.

Then again, distortion of the term is commonplace in server-side web programming frameworks, as I mentioned before. I did once look at the Wikipedia article on this subject, but it's one of those where people with no understanding of the original concept have taken over so comprehensively that it is beyond hope and needs a complete rewrite... preferably by someone who knows that Smalltalk is a programming language, not to be confused with idle chat at web developer conferences. :-)

Hmmm... model as persistent state, controller as state-change manager and view as, well, what you see -- that's pretty much the way Burbeck described it. The model may "know" how to reflect state changes (and that would include things like object-relational mapping where appropriate, maintaining relational integrity and so on), but what to change (the application logic) is and was the responsibility of the controller -- yes, even in Smalltalk 80. Some of us do go back rather a long way, you know.

I suppose it depends on what you mean by "state-change manager".

My understanding has always been that a controller's job was to translate user actions into domain-level operations to be carried out. You might start the foobazifier by clicking a toolbar icon, pressing a keyboard shortcut, or selecting a menu item, but they all have the same effect. The controller's job is to interpret those user actions to determine the required effect. The model's job is to understand what that effect means and update things accordingly.

In practice, of course, it has never really been quite that simple. Views tend to have metadata (such as the current cursor position in a document or zoom level) that are also maintained by commands from the controller, so not all data is stored in the model, only the important, domain-related state. Observer patterns get implemented so that the model can remain independent of any particular controller/view pair, but it still has to provide both an API for updates from controllers and a defined set of events that interested modules can observe.

In any case, the model's role is not just to be a thin wrapper around the database/file system/whatever. It is also the guardian of "business logic". I think one danger with the term MVC is that it suggests a system composed of only three modules. In reality, MVC is a high-level architectural pattern, and in non-trivial applications all three of those components are going to need a lot of internal structure as well. Representing domain concepts and persistent state may well be at the core of the model, but just about any code that works entirely in terms of domain concepts probably belongs within the model component somewhere.

I always thought fat models and skinny controllers were the preferred design pattern:

http://www.google.com/search?q=fat+model+skinny+controller

Reply on news.ycombinator.com