Sometimes over-simplifying things makes them more confusing. Really it's just: server • database • backend code browser • front-end code • DOM or react etc

I feel like Model View Controller is one of those things kids are told just to confuse them. Like when we tell kids that aeroplanes can fly because of the shape of the wing.

I agree with that sentiment. :) I have never found any use in any of those MVC-esque acronyms (there are probably 15 of them by now).

“You know the whole single responsibility thing? Well, here are three very high-level responsibilities.” “Great! We have an entire framework for everything!”

MVC made a bit more sense when web pages weren't SPAs or so "responsive" Back when the backend did just about everything and Javascript was a scarcity, when it was a simple backend server that got a request and responded with html, instead of the browser having it's own "router" and dynamically loading different bits of data from 13 different apis

Model, view and controller roughly corresponds to database, client (e.g browser), and server. Or at least that's a very common usage.

At that point, IMO it just obfuscates things, especially given that "roughly" part. Figuring out the exact boundaries will result in delving into details that will make the whole MVC quite meaningless in this context.

MAC -- Model, API, Controller

yep that makes more sense

> MAC -- Model, API, Controller IMO these are the components of back-end only. And front-end... who knows what it is... maybe it's a whole another application that processes something using punchcards. Then it would have another layer of MAC where they could also be a data source for something...

I've personally never bothered viewing anything under an MVC lens precisely for what you stated regarding confusion. Most modern UI libraries do not use MVC anyway, so thinking about them in an MVC lens is counterproductive

Model View Controller is an application of Object Orientation, so, in a formal sense, it would be a bit of a surprise if consultation of this august Forum dredged up a precise and favorable understanding of MVC. But I'd go out on a limb and venture that if you figured out the true meaning of MVC, you would find that a client-server SPA involved a complete MVC model on the client side, and another, complete, distinct MVC model on the server side. On the client side, "views" are visible readouts (for consumption by a person), and on the server side, "views" are JSON or similar products (for consumption on the client side).

In MVC Controller calls Model interface to retrieve some data, Model calls DB to get the data and transforms it into the Model structure, returns the Model structure to the Controller. Controller tells the View to render the returned Model structure. When the user clicks on something on the View, the View tells the Controller of the command. If the command needs to result in changing some data, Controller will call methods on the Model interface to modify the Model's data. The Model in turn will update the DB with the changes, and it will return the new Model structure with the updated data in it. Controller will tell the View to re-render itself with the new Model structure ounce again.

And then MVVM is a bit more confusing. Model and View stay the same. But the Controller is gone, replaced by a ViewModel. The ViewModel is similar to a Controller, but it also handles interactive View logic. For example, if you type in one box and it should update in another box in the View, the ViewModel would do that. As the user types in one box, the ViewModel is told, and it goes and update the data of the other box and updates the View in real-time. But this should all be done through 2-way data-bindings, so not through commands. So here, there was no going to the DB, maybe until the user clicks submits. So the ViewModel has like a View only model, that it shares with the View, as they both update that model, it updates each other accordingly. This is a separate model from the Model that is supposed to always reflect the DB state. Hence the ViewModel name for it.

MVP is more similar to MVVM, like it lets the View have commands that changes only the View, but not the DB. Where maybe the only difference is the ViewModel is supposed to be agnostic of the View, like it doesn't know what View is using the Model of the ViewModel. Where the Presenter is more coupled. So in MVVM, View changes reflect through two-way data-binding. Where a Presenter could reflect it in more direct ways.

Now with SPA... MVC + SPA: When your user interacts with your view, it makes an AJAX call to backend controller. Controller uses the Model to modify whatever data is needed for that Command. The Controller then returns back to the view the new Model, the view updates itself (using DOM manipulation, no page refresh). MVVM + SPA: When user interacts with your view, the view modifies some data-structure or object model. This data change triggers an event in the ViewModel, which as a result could decide to change other part of the data-structure/object model. Those changes would in-turn send an event to the view to refresh itself with those changes. Both ViewModel and View live in the client. When a change to the ViewModel's data should also be persisted to the DB, the ViewModel makes an AJAX server call passing in the data for the server to now use the Model to persist in the DB. MVP + SPA: When user interacts with your view, the view sends commands to the Presenter. The Presenter then tells the View to change in some way as a result. Or/And it makes an async AJAX call to the server to update the Model. View and Presenter would live in client. Model on the server.

I think... Maybe digging into routing is needed too, for better understanding of the differences. Cause now I just described how a single View is first rendered, and how user actions on it are handled, and go on to update the DB and refresh the View. But routing is what handles the choice of View to render in the first place. Or that we should render a different View. In MVC if I remember correctly, routing is handled by the Controller as well. So user commands done on the View are passed to the Controller. And the Controller decides if that command means we should now render a different View or refresh the current one. I think this is where with SPA, you could have the Controller on the client side as well if you wanted, and only the Model on the server. But sometimes it's hard to expose the backend Model directly to the Client, so there might be APIs instead that themselves use the Model under the hood. And those APIs might themselves have a Controller to manage routes for them, etc., but it's not really a MVC Controller anymore, cause there's no corresponding View. With MVVM, there's no inherent routing, the ViewModel just does two-way data-bind. I think you'd need something else to do routing. With MVP, I think the Presenter would do routing, as-in, it would call into another Presenter.

Anyways, all these patterns that are given names. You should more use them as inspo. It helps understand different way you can structure code. And you can use one of them as a way to start off an app, but it's never going to be a perfect fit. You might end up with some variation on one of them, some combination of them, something else completely, etc. And so, any real application is rarely a by-the-book implementation of one of those patterns.

There are actually multiple MVC's, unfortunately. AFAIK, the first time MVC appeared was on Smalltalk, where the idea was - Model keeps the app state, the view connects to the model via "Observers" and every interaction on the view called a "controller", that caused mutations on the Model that the view would reflect.

Then came "Rails MVC" where the Controller is basically the handler that called the DB, defined variables, and called the view to be rendered, the Model being basically "the database mapping" (it actually don't need to be that way, but multiple Rails sugar things fall down if you make a model a simple Ruby class), and the view a simple HTML

In this sense, I feel that re-frame is closer to the Smalltalk idea - the app-db is the "model", the Hiccup with its subscribers the "view", and every re-frame function that answers to dispatch is part of the "controller"

Ya, but at a high level I think it's the same concept still. You could not do Observable across the network when Rails came out. So instead they modified it to have the controller respond with the new View. Similarly, pushing the app state in a DB required some changes too. Some had the Model expand to also call the DB, some expanded the Controller to do so.

But ya, I think Smalltalk MVC looks more like MVVM but without 2-way binding?

More like "MVVM looks like Smalltalk MVC, but with 2-way binding" I guess 😄

guys, this has been immensely helpful actually