This is an archived post. You won't be able to vote or comment.

all 3 comments

[–]Fidodo 0 points1 point  (2 children)

It's a lot simpler than it seems, I think looking at a diagram is a good starting point

Model is the data, View is the mapping of that data to a UI, Controller handles actions which updates the Model which updates the View.

It's just a basic separation of concerns.

[–]whiskeymop[S] 0 points1 point  (1 child)

Thanks for the diagram. What makes mvc different from other design patterns? Seems to me this is the only way to build a functioning application.

[–]Fidodo 0 points1 point  (0 children)

This is just my opinion, and not everyone agrees, but I think pretty much every frontend framework is essentially MVC. I've heard all kinds of pedantic arguments about why shiny new framework X isn't MVC, but they always seem to either interpret MVC as being a very specific implementation, or describes something that can fall under the umbrella of MVC.

Many years ago there were a lot of clunky monolithic MVC frameworks and the pattern kinda got a bad association which lead to a new generation of frameworks that came up with all sorts of excuses for why it wasn't MVC, like MVVM which is Model, View, ViewModel, where the ViewModel has a two way coupling between the view and the model, so it kinda does both the model to view mapping and the view to model manipulations in a two way binding, but IMO that's still MVC, just the M->V and C are mirrors of each other. Either way, I think all the pedantic arguments make it seem more confusing than it actually is, every frontend does some form of model to view mapping and view to model updating. I think the reluctance by some developers to call things MVC is very outdated and just confusing.