4 ms·

Interesting link. Do you know the original context? I’d be the first to agree that a lot of back-end web frameworks have wildly distorted the original idea of M

Interesting link. Do you know the original context? I’d be the first to agree that a lot of back-end web frameworks have wildly distorted the original idea of MVC, and in many cases completely missed the point of why it was useful. However this is the first time I’ve seen anything from the original Smalltalk days that presented the relationships like this, with views affecting models and a controller implicitly being related to multiple views.

rubiquity 13y ago
The original MVC was invented in the context of a fat client which were desktop-esque applications back in the day. In the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context which is what Rails and many other frameworks have done. Now with browsers and JavaScript performance being better than ever, preserving state seems possible so a more "original" MVC implementation can (possibly, everyone is still debating this these days) work on the client side. Rails and the other MVC frameworks don't just focus on the client-side, however. They are also deeply involved with the database and everything in between so a pure implementation of MVC is out of their reach. On the Web in the next 5-10 years maybe we will see more frameworks separating the concerns of the Web server/database and the client-side. Once we break those apart you can have a Smalltalk style MVC implementation on the client-side and organize your "back-end" code to your hearts desire or use a back-end specifc framework to guide you there.
- Chris_Newton 13y ago
  Now with browsers and JavaScript performance being better than ever, preserving state seems possible so a more "original" MVC implementation can (possibly, everyone is still debating this these days) work on the client side. There is little need to debate that point. Doing MVC-style architecture on the browser side works just fine. One of my long-term projects is a relatively large web application that uses something very close to the original MVC idea, with a central model that holds all the state and then a few dozen view-controller pairs that handle all the ways of interacting with it. This architecture has served me well for several years now, and the design has proven to be very easy to maintain and adapt to changing requirements. (In practice I add a fourth type of component in the web context, a “store” that is responsible for communicating with the server, and I define a small number of additional relationships to go with it because it doesn’t fit into any of the other three categories. Even then, the store acts somewhat like a view-controller pair for most purposes, and the cases where it doesn’t are mostly things I might do differently with the wisdom of hindsight.) On the Web in the next 5-10 years maybe we will see more frameworks separating the concerns of the Web server/database and the client-side. I’m not sure why we need any distinction between them. Ultimately, we’re just writing a distributed application, which happens to run using something like HTTP as a communications protocol in this case. All the usual concepts about maintaining state and actions that have side effects apply, and all the usual arguments about separating such concerns apply. What makes you think we can’t use these ideas already today?
davidcuddeback 13y ago
The original context was for building interactive GUIs. I think you're right that web frameworks' concept of MVC is different than the original context because of the request/response cycle of HTTP. However, understanding the original ideas of MVC has helped me a ton even when writing backend code for the web. Trygve Reenskaug actually setup a web page to explain how MVC was originally conceived [1]. My main take-away was that models correspond with the user's mental model while using the application: "The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly." The most important (IMO) implication of this is that your models aren't limited to data that exists in a database, which is a mistake that I see a lot of web developers make. http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
- Chris_Newton 13y ago
  Sorry, I wasn’t clear. I’m familiar with the original GUI-based work, or at least I thought I was. However, this is the first time I’ve seen any material from those early days that suggested having the view affect the model, as opposed to being a mere observer, passive or otherwise, and having controllers responsible for all changes of state. It’s also the first time I’ve seen an early source suggest having one controller deal with multiple views, as opposed to possibly having multiple controller-view pairs associated with the same underlying data but with each view having its own associated controller. I’ve seen variations with views and controllers nested and using some form of delegation/bubbling if the presentation is complicated, but that’s not quite the same thing. The only original papers I’d seen previously, even those that I thought included Reenskaug as an author, already had the characteristic triangle arrangement with one-way traffic from the model to the view and with a 1:1 view:controller relationship, so I was interested to know the origin of the paper that icebraining linked to. Your link answers that question, so thanks for that.
  - dfox 13y ago
    In the original (ST and desktop GUI centric) MVC, controller and view were essentially interfaces. View is something that can draw window on screen and controller is something that processes/redistributes events from input devices. On the other hand model is simply something that can be hooked up to that, ie. stores state accessible by views and controllers and notifies views of state changes. The idea of view directly modifying models comes from fact that in many cases there was class named FooView, that acted both as view and controller (which generally makes sense because the low level GUI logic is same for both). Also models represented not only the actual data but also various parts of GUI state itself (eg. position of scrollbar).
tieTYT 13y ago
The original flaw, if you ask me, is the naming. WTF is a model? WTF is a controller? WTF is a view? You can (and I have) explained this to a newbie for an hour and they still won't get it. They may as well have named it 123. At least that wouldn't make you guess at what the naming signifies.
- dasil003 13y ago
  Well obviously the nuance is going to be lost on someone who hasn't actually programmed the type of system the pattern refers to. There's no way for someone to grok it without a mental model of what the system needs to accomplish. However with that experience it's really not that hard to understand.
  - tieTYT 13y ago
    I disagree. That's not obvious. It's relatively easy to explain parallelism, concurrency, recursion, currying, idempotency, the visitor pattern, etc. etc. This is different. MVC names are really annoying and poorly chosen. Every time I think of the pattern, I have to make an association between each word of the pattern and its meaning. For example, the Model of MVC consists of business logic and sometimes what people refer to as... models. The business logic controls how models are modified. The Controller doesn't. The Controller controls very little when the system is correctly architect-ed, especially when you have multiple UIs. Really, the View is the only one without ambiguity. But even so, I still have to google from time to time to remember who is allowed to know about who and who notifies who of what... A better name, and this is literally off the top of my head, would be "Business Layer, View and Event Translator". Edit: Having thought about it more, I decided to change the word Presentation to View in my "better name" suggestion.
    - e12e 13y ago
      > A better name, and this is literally off the top of my head, would be "Business Layer, View and Event Translator". That's not far off the original meaning AFAIK. It used to be called MVCU - model-view-controller-user. The "model" is the idea of the data as it exists in the users mind, the view is how the system presents it, and the controller works with what the user "do" with the model through the view. It gets confused if you don't realize there are two data models: the "data" model - how the data is modelled in the abstract (and confusingly, internally in the program/database) -- that is distinct from the model in MVC. So the original MVC "model" is closer to "domain model" than to "data model". Now, in the dark 90s, when everyone had forgotten that users existed, something that no-one would realize until "agile" emerged and surprised everyone, these two "models" got mixed up -- and no one was able to understand this MVC thing ;-)

rubiquity 13y ago

The original MVC was invented in the context of a fat client which were desktop-esque applications back in the day. In the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context which is what Rails and many other frameworks have done. Now with browsers and JavaScript performance being better than ever, preserving state seems possible so a more "original" MVC implementation can (possibly, everyone is still debating this these days) work on the client side. Rails and the other MVC frameworks don't just focus on the client-side, however. They are also deeply involved with the database and everything in between so a pure implementation of MVC is out of their reach. On the Web in the next 5-10 years maybe we will see more frameworks separating the concerns of the Web server/database and the client-side. Once we break those apart you can have a Smalltalk style MVC implementation on the client-side and organize your "back-end" code to your hearts desire or use a back-end specifc framework to guide you there.

Chris_Newton 13y ago
Now with browsers and JavaScript performance being better than ever, preserving state seems possible so a more "original" MVC implementation can (possibly, everyone is still debating this these days) work on the client side. There is little need to debate that point. Doing MVC-style architecture on the browser side works just fine. One of my long-term projects is a relatively large web application that uses something very close to the original MVC idea, with a central model that holds all the state and then a few dozen view-controller pairs that handle all the ways of interacting with it. This architecture has served me well for several years now, and the design has proven to be very easy to maintain and adapt to changing requirements. (In practice I add a fourth type of component in the web context, a “store” that is responsible for communicating with the server, and I define a small number of additional relationships to go with it because it doesn’t fit into any of the other three categories. Even then, the store acts somewhat like a view-controller pair for most purposes, and the cases where it doesn’t are mostly things I might do differently with the wisdom of hindsight.) On the Web in the next 5-10 years maybe we will see more frameworks separating the concerns of the Web server/database and the client-side. I’m not sure why we need any distinction between them. Ultimately, we’re just writing a distributed application, which happens to run using something like HTTP as a communications protocol in this case. All the usual concepts about maintaining state and actions that have side effects apply, and all the usual arguments about separating such concerns apply. What makes you think we can’t use these ideas already today?

davidcuddeback 13y ago

The original context was for building interactive GUIs. I think you're right that web frameworks' concept of MVC is different than the original context because of the request/response cycle of HTTP. However, understanding the original ideas of MVC has helped me a ton even when writing backend code for the web. Trygve Reenskaug actually setup a web page to explain how MVC was originally conceived [1]. My main take-away was that models correspond with the user's mental model while using the application: "The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly." The most important (IMO) implication of this is that your models aren't limited to data that exists in a database, which is a mistake that I see a lot of web developers make. http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

Chris_Newton 13y ago
Sorry, I wasn’t clear. I’m familiar with the original GUI-based work, or at least I thought I was. However, this is the first time I’ve seen any material from those early days that suggested having the view affect the model, as opposed to being a mere observer, passive or otherwise, and having controllers responsible for all changes of state. It’s also the first time I’ve seen an early source suggest having one controller deal with multiple views, as opposed to possibly having multiple controller-view pairs associated with the same underlying data but with each view having its own associated controller. I’ve seen variations with views and controllers nested and using some form of delegation/bubbling if the presentation is complicated, but that’s not quite the same thing. The only original papers I’d seen previously, even those that I thought included Reenskaug as an author, already had the characteristic triangle arrangement with one-way traffic from the model to the view and with a 1:1 view:controller relationship, so I was interested to know the origin of the paper that icebraining linked to. Your link answers that question, so thanks for that.
- dfox 13y ago
  In the original (ST and desktop GUI centric) MVC, controller and view were essentially interfaces. View is something that can draw window on screen and controller is something that processes/redistributes events from input devices. On the other hand model is simply something that can be hooked up to that, ie. stores state accessible by views and controllers and notifies views of state changes. The idea of view directly modifying models comes from fact that in many cases there was class named FooView, that acted both as view and controller (which generally makes sense because the low level GUI logic is same for both). Also models represented not only the actual data but also various parts of GUI state itself (eg. position of scrollbar).

tieTYT 13y ago

The original flaw, if you ask me, is the naming. WTF is a model? WTF is a controller? WTF is a view? You can (and I have) explained this to a newbie for an hour and they still won't get it. They may as well have named it 123. At least that wouldn't make you guess at what the naming signifies.

dasil003 13y ago
Well obviously the nuance is going to be lost on someone who hasn't actually programmed the type of system the pattern refers to. There's no way for someone to grok it without a mental model of what the system needs to accomplish. However with that experience it's really not that hard to understand.
- tieTYT 13y ago
  I disagree. That's not obvious. It's relatively easy to explain parallelism, concurrency, recursion, currying, idempotency, the visitor pattern, etc. etc. This is different. MVC names are really annoying and poorly chosen. Every time I think of the pattern, I have to make an association between each word of the pattern and its meaning. For example, the Model of MVC consists of business logic and sometimes what people refer to as... models. The business logic controls how models are modified. The Controller doesn't. The Controller controls very little when the system is correctly architect-ed, especially when you have multiple UIs. Really, the View is the only one without ambiguity. But even so, I still have to google from time to time to remember who is allowed to know about who and who notifies who of what... A better name, and this is literally off the top of my head, would be "Business Layer, View and Event Translator". Edit: Having thought about it more, I decided to change the word Presentation to View in my "better name" suggestion.
  - e12e 13y ago
    > A better name, and this is literally off the top of my head, would be "Business Layer, View and Event Translator". That's not far off the original meaning AFAIK. It used to be called MVCU - model-view-controller-user. The "model" is the idea of the data as it exists in the users mind, the view is how the system presents it, and the controller works with what the user "do" with the model through the view. It gets confused if you don't realize there are two data models: the "data" model - how the data is modelled in the abstract (and confusingly, internally in the program/database) -- that is distinct from the model in MVC. So the original MVC "model" is closer to "domain model" than to "data model". Now, in the dark 90s, when everyone had forgotten that users existed, something that no-one would realize until "agile" emerged and surprised everyone, these two "models" got mixed up -- and no one was able to understand this MVC thing ;-)