MVC and Purity
blog.ezyang.com
blog.ezyang.com
The most useful principle that comes with MVC is also the most straightforward and intuitive: decouple the core logic from the interface (user or otherwise).
The rest, like the enigmatic Controller, obviously has no common and consistent meaning among programmers. I suspect that the original meaning has been lost to reinterpretation over many generations of changing technology. But if the original meaning really matters to you that much, you are probably doing theology and not engineering.
The key thing about real MVC is to separate not just the I/O details from the model, but the input details from the output. The view's only purpose is to render data from the model to some output device so the user can see it (or otherwise detect it). No matter how many monads you use to dress this up, it is fundamentally effectful: it updates the screen, plays sounds through speakers, etc.
This is where the confusion with web-based "MVC" comes in. If all your view does is generate some HTML as pure data, it isn't much of a view at all. No-one can see the results. You need a web server sitting on top, to take that HTML and send it back to the browser client using HTTP, and in the traditional sense of MVC that would be part of the view code as well.
This may be a useful distinction, in that it provides separation between the (necessarily impure) outside-facing code and the (potentially pure) rendering operation. A view module can be built up in layers from submodules just like any other part of a software system, and likewise the top layers can be effectful while depending only on pure code below. But the view module as a whole is always effectful, or it serves no purpose.
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.
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. :-)
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.
Fundamentally, MVC is a three-way relationship, designed to support an interative user interface. I don't see what is gained by trying to shoehorn a web-based system with a linear structure into those boxes. It's not wrong, it's just different, but it is unhelpful to call something different by the same name.
Funnily enough, the MVC idea does work rather well for the client side of a web-based interface, as the event model in JavaScript lends itself quite neatly to handling by a controller, and the whole HTML/DOM set-up lends itself to rendering by a view.