MVC Paper
James Coplien
Andrzej Krzywda
Someone here in the DCI community here wrote a paper some years ago now on what MVC is *really* about, and published it somewhere on the web. Who was it, and where it the paper?
--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/object-composition/E926533D-C953-4E0B-BF46-47F99E8D832E%40gmail.com.
Matthew Browne
Hi Cope,
I'm guessing this isn't what you're remembering either, but
Andreas wrote a blog article about MVC based on consultation with
Trygve and you, and shared it with the group at the time:
https://blog.encodeart.dev/rediscovering-mvc
Matt Browne (he/him)
To view this discussion visit https://groups.google.com/d/msgid/object-composition/CAPK7fLQvZktEmRQKM4-btRoFN2_A5uhoWyyx02tSjRM_aXF%2BYg%40mail.gmail.com.
Raoul Duke
oh wow maybe i finally understand what a ViewModel is and where it came from!
James Coplien
To view this discussion visit https://groups.google.com/d/msgid/object-composition/3215556e-5cd4-47d7-b11e-d475f9532dba%40gmail.com.
Matthew Browne
Since we're talking about that article, there's one thing in it that I don't think is quite right:
If you agree that the View should be an object, finding a MVC web framework that allows us to create Views as simple objects isn't that easy. Mithril is a shining exception however. It lets one focus on the system architecture instead of structure. It uses View Models, but they aren't a requirement. Svelte is another example that embraces the natural coupling of MVC. Overall, the situation is improving with the "components" approach, which, in light of the above information, is really MVC in disguise.
This implies that if your views aren't objects in a really obvious way like in Mithril, that you're not doing full MVC, but I think something that looks more like an HTML template can still be a view object. For example, in React and in Solid.js (among others), you define your UI components as functions (rather than classes) and you use JSX to specify the HTML and child components, but they're still effectively stateful objects behind the scenes. (Or consider this new framework that introduces a 'component' keyword.) The above quote somewhat acknowledges this in the last sentence, but I think the idea that a library like Mithril is more "real" MVC than the above examples is quite subjective.
Another interesting thing I came across recently (although the term is actually over 11 years old now) is the concept of Model-View-Intent, which is described well in this article. With modern libraries/frameworks, a traditional Controller isn't usually needed, because traditional Controllers are mainly just plumbing. I think Model-View-Intent fits nicely into the original goals of MVC (at least when it's done well), and that it even qualifies as MVC since it fulfills the most important patterns in Trygve's draft pattern language for MVC.
I think Model-View-Intent can be just as user-centric as the original MVC; after all, it focuses on the user's intent when they perform actions in the UI.
This is a trend you see everywhere now: MV-something, where the Controller has been largely replaced by plumbing that the library takes care of for you. Another example is Multisynq's (formerly Croquet's) Model-View-Synchronizer pattern.
To view this discussion visit https://groups.google.com/d/msgid/object-composition/A81327C6-63B9-4A04-8270-FC069113D31E%40gmail.com.
James Coplien
On 20 Mar 2026, at 13.17, Matthew Browne <mbro...@gmail.com> wrote:where the Controller has been largely replaced by plumbing that the library takes care of for you
Matthew Browne
In UI-component-based frameworks, the stacking/ordering of Views is just another component, often called App. For example, App might return this set of components:
<NavMenu items={...} />
<Main ...>
<Sidebar ... />
</Main>
And you use it like this:
<App />
I am coming from the context of web development. For desktop and mobile apps it might be different.
But you might be talking about routing—handling the user's navigation from one part of the app to another (or one "page" to another for a web app). For that, there is indeed often something like a Controller.
James Coplien
--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/object-composition/7200dd65-e809-48a9-8872-f4bb488d2dc6%40gmail.com.
Matthew Browne
For an app with routing, there would typically be a router component...placement varies depending on the framework e.g.:
<Router
config={routerConfig}>
<App />
</Router>
Or it might be part of the App component:
function App() {
...
return (
...
<body>
<GlobalNavMenu />
<Router config={routerConfig} />
</body>
)
)
To view this discussion visit https://groups.google.com/d/msgid/object-composition/0732B605-EF8D-4040-B5DF-53351079EFB2%40yahoo.com.
Matthew Browne
James Coplien
On 20 Mar 2026, at 22.58, Matthew Browne <mbro...@gmail.com> wrote:I was talking more about controllers for individual Views.
Matthew Browne
Isn't it also the job of the controller to pass data from the model (or the model(s) themselves) to the views, and to process events from the views and update the model(s)?
I remember that in Trygve's Prokon
(planning) example, there's just one Model and just one
Controller, and I'm guessing this reflects how Trygve typically
implemented MVC, along with other developers in the early days.
But I thought the pattern where you have multiple instances of
Controllers and Models also qualified as MVC. I think a visual
will help here...consider this diagram from an
article by Martin Fowler:
In this type of architecture, there would be more controllers for other UI components (not just Text Field obviously). You could also have (and should have in many cases) the same Controller keeping multiple Views in sync, but there isn't just one Controller for the whole app.
I thought that this type of architecture was also what Andreas was referring to in his article when he referred to Model, View, and Controller as roles in this part:
- In simple cases, the Model, View and Controller roles may be played by the same object. Example: A scroll bar.
- The View and Controller roles may be played by the same object when they are very tightly coupled. Example: A Menu.
- In the general case, they can be played by three different objects. Example: An object-oriented design modeller.
He also included this direct quote from Trygve about how to handle parent-child relationships between Views:
Let a View play two roles: Let it be managed by its Controller in the usual manner and, at the same time, be (sub)Controller that manages a number of subviews.
I feel like there's a lot of confusion around this topic in general, and what does or does not qualify as MVC. Some quotes from Trygve that I think are worth keeping in mind:
"[MVC] can be realized in many different ways" (source)
"I don't see MVC as a straight jacket, but as an inspiration. I let it guide my implementations, but not constrain me when other solutions are clearly more readable." (source)