4 ms·

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

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).
  - Chris_Newton 13y ago
    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). Sure, as an implementation detail that might be how things are done, but that’s different from conceptually having the view responsible for changes of the model’s state, no? Also models represented not only the actual data but also various parts of GUI state itself (eg. position of scrollbar). I think everyone who tries MVC probably comes up against the “Where does view metadata go?” question sooner or later. FWIW, I think treating that kind of transient state as part of the model is unwise. If it’s metadata that applies to one specific view, as with your scrollbar example, it can live on the view. The corresponding controller can then send suitable commands to the view to update it in response to user actions, and the model is completely unaffected. If it’s metadata that is shared among multiple views, such as which element of a system has a focus/active state or something like a clipboard/kill ring, then I prefer to introduce a completely separate component. Each affected view will observe that metadata component in the same way it observes the model, and therefore each corresponding controller can update that metadata component in response to a user action on its view and all affected views will react. Often, the metadata component may itself also observe the real model, so that for example if an item with focus is deleted from the model it will also cease to be recorded as the current selection in the metadata for any views. This approach isn’t quite as tidy as pure MVC, but it does maintain clear responsibilities and collaborations between all of the components involved. In particular, it maintains the general design principles of MVC, and it does prevent anything that isn’t really persistent state or related business logic from polluting the model.
e12e 13y ago
In addition to the original stuff on MVC, the newer stuff on DCI[1](Data, Context and Interaction) is also illuminating wrt one way to progress with software architecture for interactive/event driven applications. [1] https://en.wikipedia.org/wiki/Data,_Context,_and_Interaction https://en.wikipedia.org/wiki/Data,_Context,_and_Interaction

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).
- Chris_Newton 13y ago
  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). Sure, as an implementation detail that might be how things are done, but that’s different from conceptually having the view responsible for changes of the model’s state, no? Also models represented not only the actual data but also various parts of GUI state itself (eg. position of scrollbar). I think everyone who tries MVC probably comes up against the “Where does view metadata go?” question sooner or later. FWIW, I think treating that kind of transient state as part of the model is unwise. If it’s metadata that applies to one specific view, as with your scrollbar example, it can live on the view. The corresponding controller can then send suitable commands to the view to update it in response to user actions, and the model is completely unaffected. If it’s metadata that is shared among multiple views, such as which element of a system has a focus/active state or something like a clipboard/kill ring, then I prefer to introduce a completely separate component. Each affected view will observe that metadata component in the same way it observes the model, and therefore each corresponding controller can update that metadata component in response to a user action on its view and all affected views will react. Often, the metadata component may itself also observe the real model, so that for example if an item with focus is deleted from the model it will also cease to be recorded as the current selection in the metadata for any views. This approach isn’t quite as tidy as pure MVC, but it does maintain clear responsibilities and collaborations between all of the components involved. In particular, it maintains the general design principles of MVC, and it does prevent anything that isn’t really persistent state or related business logic from polluting the model.

e12e 13y ago

In addition to the original stuff on MVC, the newer stuff on DCI[1](Data, Context and Interaction) is also illuminating wrt one way to progress with software architecture for interactive/event driven applications. [1] https://en.wikipedia.org/wiki/Data,_Context,_and_Interaction https://en.wikipedia.org/wiki/Data,_Context,_and_Interaction