4 ms·

MVC and Purity

24 points by fogus 16y ago

stretchwithme 16y ago
What is meant by the expression "code purity"?
- superk 16y ago
  http://www.haskell.org/haskellwiki/Functional_programming#Purity http://www.haskell.org/haskellwiki/Functional_programming#Pu...
Chris_Newton 16y ago
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 16y ago
  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 16y ago
    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 16y ago
      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. :-)
      - 16y ago
- ezyang 16y ago
  Good point, but I think you’re thinking too much about the single client case. Consider if you have an application that serves multiple clients at the same time: the side effect of the view model is no longer “update a screen” or “play a sound through a speaker”, it’s “update screen X” or “play a sound through user X’s speakrs.” You can make a case for making this logic live in the logic, but it should start making you itchy, and I think this sort of routing functionality should live in the controller. In which case, your life is a lot easier if the View is pure.
  - Chris_Newton 16y ago
    I'm sorry, but I don't see how what I described is limited to a single client. There is no reason you could not have your model running on one machine, and a view/controller pair running on another. If you have multiple clients, just start a view/controller process on each of them. Indeed, I have worked on systems with essentially this architecture, and it works fine. 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.
extension 16y ago
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.
- contextfree 16y ago
  I think M/V separation is the basic principle and elaborations beyond that are more context dependent, so the next level of generally applicable expertise beyond grasping the basic concept requires you to be familiar with a whole range of patterns and considerations for what the stuff in the middle should be.
- ezyang 16y ago
  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.

MVC and Purity

24 points by fogus 16y ago

stretchwithme 16y ago

What is meant by the expression "code purity"?

superk 16y ago
http://www.haskell.org/haskellwiki/Functional_programming#Purity http://www.haskell.org/haskellwiki/Functional_programming#Pu...

Chris_Newton 16y ago

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 16y ago
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 16y ago
  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 16y ago
    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. :-)
    - 16y ago
ezyang 16y ago
Good point, but I think you’re thinking too much about the single client case. Consider if you have an application that serves multiple clients at the same time: the side effect of the view model is no longer “update a screen” or “play a sound through a speaker”, it’s “update screen X” or “play a sound through user X’s speakrs.” You can make a case for making this logic live in the logic, but it should start making you itchy, and I think this sort of routing functionality should live in the controller. In which case, your life is a lot easier if the View is pure.
- Chris_Newton 16y ago
  I'm sorry, but I don't see how what I described is limited to a single client. There is no reason you could not have your model running on one machine, and a view/controller pair running on another. If you have multiple clients, just start a view/controller process on each of them. Indeed, I have worked on systems with essentially this architecture, and it works fine. 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.

extension 16y ago

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.

contextfree 16y ago
I think M/V separation is the basic principle and elaborations beyond that are more context dependent, so the next level of generally applicable expertise beyond grasping the basic concept requires you to be familiar with a whole range of patterns and considerations for what the stuff in the middle should be.
ezyang 16y ago
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.