
MVC and Purity - fogus
http://blog.ezyang.com/2010/07/mvc-and-purity/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ezyang+%28Inside+245s%29&utm_content=Google+Reader
======
extension
If you have to deliberate on a design pattern on this abstract and dogmatic
level, it is unlikely to be making you more productive.

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.

~~~
ezyang
When I do software engineering, I use architectural principles to make
decisions for me. I don’t have to decide where the HTML rendering code will go
because the Model-View principle has made it clear. Furthermore, I get annoyed
when the architectural principle fails to give a me a decision, but I get the
feeling that it should (the example I gave here was input validation, which I
now believe soundly should live in the model). In this case, I can either make
an ad hoc decision or think more carefully about the architectural principle.
Both practices are valuable.

------
Chris_Newton
Interesting article, but I don't buy the conclusion. I think this is partly
because the term MVC has been distorted considerably from its original meaning
when used in the context of web sites.

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.

~~~
Periodic
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.

~~~
stan_rogers
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).

~~~
Chris_Newton
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. :-)

~~~
stan_rogers
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.

~~~
Chris_Newton
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.

------
stretchwithme
What is meant by the expression "code purity"?

~~~
superk
[http://www.haskell.org/haskellwiki/Functional_programming#Pu...](http://www.haskell.org/haskellwiki/Functional_programming#Purity)

