I am greatly interested in the topic of GUI app architecture, and would like to “hear” your opinion on the topic. Here is the recent HN thread as well. One commenter there put it well, I think...
I am greatly interested in the topic of GUI app architecture, and would like to “hear” your opinion on the topic.
One commenter there put it well, I think (paraphrasing):
the model is basically a headless version of your whole application. It shouldn’t be too hard to port its desktop app version to a TUI, by only touching the View and Controller parts.
Also, the controller and view should be viewed as a pair, “two halves” of the same thing, one is output, the other is input-oriented.
Of course the actually hard part is sticking to this architecture, because the respective boundaries often end up less blurry than ideal.
What is your take/experience, either on the architecture, or having written programs like this? Do you think a better model exists?
I also like this comment (and they source from OG author later in thread): But seperately, the way I see MVC traditionally used, I think could also work well for the web. Just not the "unique per...
I also like this comment (and they source from OG author later in thread):
The M in MVC has come to mean “data model,” but it originally referred to the “mental model” of the user. What kind of thing are we trying to manipulate and what is the user’s mental model of such a thing?
How about a bank account? A mental model of a bank account would include useful operations like deposit, withdraw, transfer, checkBalance, and these would be the methods on the object. The data schema and the persistence would be necessary, of course, but an implementation detail. Models were smart and mapped to human perceptions of a thing, rather than dumb data persistence layers.
These kind of business logic operations have often been moved into controllers, which couldn’t have been further from the original intention.
But seperately, the way I see MVC traditionally used, I think could also work well for the web. Just not the "unique per user" web that now dominates.
In my mind, a workable MVC for the web could work like this, and probably does way more than I think it does. I'm using Tildes as an arbitrary example of how this could work.
So I'm looking at this page, which is mostly rendered server-side, a view. I'm typing in the comment box, and when I hit "Post comment", it POSTS to the controller. The controller writes to the database (model), which has a trigger on the comment table which then updates the view. I get the new view when I refresh the page.
It's essentially static-site generation happening whenever a POST is received to the controller. I could see how for 'hot' topics (less than a week old), keeping pre-rendered views in-memory on the server, could use less resources than generating them on every GET. Particularly for a site like Tildes where 10x or more users read than post.
Good article. I've been heavily using a proprietary custom MVVM-MVC developed internally with vanilla JS in the front-end and ASP.NET MVC in the back-end (thus the weird overkill acronym). We...
Good article. I've been heavily using a proprietary custom MVVM-MVC developed internally with vanilla JS in the front-end and ASP.NET MVC in the back-end (thus the weird overkill acronym). We designed and created this 10+ years ago, before React and Angular were more popular (although even if we did it again today I don't think we'd be able to leverage those frameworks anyways).
There are trade offs to every approach, but the main thing I've learned over the years is: do not mix your business logic and your view / contract logic. Whatever you do, keep the business logic in separate, well defined classes and services that have absolutely no idea what the UI or contracts are doing.
This has an upfront cost, but it pays off massively later. And in general this was the entire goal of MVC from the beginning, but how one approaches it is largely based on the application itself and I don't think any "one rule" should be applied.
There's an early discussion on the C2 Wiki: What's a Controller Anyway. The article treats Smalltalk-80 as the beginning and it wasn't, but close enough. It talks about how Java framework...
There's an early discussion on the C2 Wiki: What's a Controller Anyway. The article treats Smalltalk-80 as the beginning and it wasn't, but close enough. It talks about how Java framework designers and book authors borrowed the MVC acronym and reinterpreted it for their own ends.
This has happened many times. UI framework designers like to reuse the words even when they only somewhat fit the new framework.
Recently, "controller" has shrunk to almost nothing. In a React web application, for example, there is no controller. A component will create event callbacks that call functions to update the model. That's it. Polling the keyboard isn't something you need to do anymore since you will get a high-level event like "text entered into text box".
It has to be high-level because input methods are very complicated nowadays. There's a lot of variation due to internationalization and accessibility features. Only operating systems and web browsers know how to do text input and you really don't want to implement that.
Smalltalk had to do everything itself, so it was often very low-level, like a game engine that polls for input directly. It was a research project and modern event handling hadn't been invented yet.
I don't think there's much point in debating what MVC means anymore since it's gotten so fuzzy. You can define it to mean what you want, but maybe it's better to use different words?
I am greatly interested in the topic of GUI app architecture, and would like to “hear” your opinion on the topic.
Here is the recent HN thread as well.
One commenter there put it well, I think (paraphrasing):
Also, the controller and view should be viewed as a pair, “two halves” of the same thing, one is output, the other is input-oriented.
Of course the actually hard part is sticking to this architecture, because the respective boundaries often end up less blurry than ideal.
What is your take/experience, either on the architecture, or having written programs like this? Do you think a better model exists?
I also like this comment (and they source from OG author later in thread):
But seperately, the way I see MVC traditionally used, I think could also work well for the web. Just not the "unique per user" web that now dominates.
In my mind, a workable MVC for the web could work like this, and probably does way more than I think it does. I'm using Tildes as an arbitrary example of how this could work.
So I'm looking at this page, which is mostly rendered server-side, a view. I'm typing in the comment box, and when I hit "Post comment", it POSTS to the controller. The controller writes to the database (model), which has a trigger on the comment table which then updates the view. I get the new view when I refresh the page.
It's essentially static-site generation happening whenever a POST is received to the controller. I could see how for 'hot' topics (less than a week old), keeping pre-rendered views in-memory on the server, could use less resources than generating them on every GET. Particularly for a site like Tildes where 10x or more users read than post.
Good article. I've been heavily using a proprietary custom MVVM-MVC developed internally with vanilla JS in the front-end and ASP.NET MVC in the back-end (thus the weird overkill acronym). We designed and created this 10+ years ago, before React and Angular were more popular (although even if we did it again today I don't think we'd be able to leverage those frameworks anyways).
There are trade offs to every approach, but the main thing I've learned over the years is: do not mix your business logic and your view / contract logic. Whatever you do, keep the business logic in separate, well defined classes and services that have absolutely no idea what the UI or contracts are doing.
This has an upfront cost, but it pays off massively later. And in general this was the entire goal of MVC from the beginning, but how one approaches it is largely based on the application itself and I don't think any "one rule" should be applied.
There's an early discussion on the C2 Wiki: What's a Controller Anyway. The article treats Smalltalk-80 as the beginning and it wasn't, but close enough. It talks about how Java framework designers and book authors borrowed the MVC acronym and reinterpreted it for their own ends.
This has happened many times. UI framework designers like to reuse the words even when they only somewhat fit the new framework.
Recently, "controller" has shrunk to almost nothing. In a React web application, for example, there is no controller. A component will create event callbacks that call functions to update the model. That's it. Polling the keyboard isn't something you need to do anymore since you will get a high-level event like "text entered into text box".
It has to be high-level because input methods are very complicated nowadays. There's a lot of variation due to internationalization and accessibility features. Only operating systems and web browsers know how to do text input and you really don't want to implement that.
Smalltalk had to do everything itself, so it was often very low-level, like a game engine that polls for input directly. It was a research project and modern event handling hadn't been invented yet.
I don't think there's much point in debating what MVC means anymore since it's gotten so fuzzy. You can define it to mean what you want, but maybe it's better to use different words?