Your description of the controller is actually very much more like the description of the "presenter" in MVP.
It's a subject with quite a lot of conflicting information, but this is how I recall it from the 2000s.
The presenter gets info from the model, then serves it to the View. The view has (as you say) no idea who the model is, to ensure decoupling. It does however know how to send inputs back to the presenter.
In traditional MVC, the view DOES know the model and DOES receive data from it directly. The view comes first, so to say and displays the data. UI events on the view will then call the controller who manages these inputs and calls the model as appropriate.
I assume there is quite a confusion with the terms MVC going on:
the orginal meaning from the days of PARC
the meaning which AFAIK was made popular with the Rails framework (which is referenced here), where your Controllers (or oftentimes called endpoints - although this term has a history of itselves) are where your requests are routed to (from the front controller), and which -the term as well as the architecture - was adopted by most of the frameworks after that
and now we live in the age of client side MVC \o/
I would not say that the classical one is the correct one, but that one has to clarify what is meant. And comparing what is referenced in a conversation to one of the other meanings might not always be helpful.
I have the opinion that as long as nothing is wrong with a definition, we shouldn't change it.
There was nothing wrong with MVC; it was just different than MVP, yet we inject the meaning of MVP into MVC and call that the new meaning of MVC. All that while the original meaning of MVC is now lost and now both things mean the same thing.
Also that last sentence is kind of eye opening, because it implies that as long as I reference something, even when everyone else has a different definition in their heads, my definition trumps theirs...
Basically we change defitinions of things we misunderstood because that is easier than solving our cognitive dissonance internally
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your description of the controller is actually very much more like the description of the "presenter" in MVP.
It's a subject with quite a lot of conflicting information, but this is how I recall it from the 2000s.
The presenter gets info from the model, then serves it to the View. The view has (as you say) no idea who the model is, to ensure decoupling. It does however know how to send inputs back to the presenter.
In traditional MVC, the view DOES know the model and DOES receive data from it directly. The view comes first, so to say and displays the data. UI events on the view will then call the controller who manages these inputs and calls the model as appropriate.
I assume there is quite a confusion with the terms
MVC
going on:Rails
framework (which is referenced here), where yourControllers
(or oftentimes calledendpoints
- although this term has a history of itselves) are where your requests are routed to (from the front controller), and which -the term as well as the architecture - was adopted by most of the frameworks after thatI would not say that the classical one is the correct one, but that one has to clarify what is meant. And comparing what is referenced in a conversation to one of the other meanings might not always be helpful.
I have the opinion that as long as nothing is wrong with a definition, we shouldn't change it.
There was nothing wrong with MVC; it was just different than MVP, yet we inject the meaning of MVP into MVC and call that the new meaning of MVC. All that while the original meaning of MVC is now lost and now both things mean the same thing.
Also that last sentence is kind of eye opening, because it implies that as long as I reference something, even when everyone else has a different definition in their heads, my definition trumps theirs...
Basically we change defitinions of things we misunderstood because that is easier than solving our cognitive dissonance internally