This is totally relative, it doesn’t necessarily matter how the Controller reads the Model data or how it sends data to the Model to validate, what matters is that only the controller has access to the Model, so if what you explained is exactly this
Mvc does not depend directly on programming and much less on OOP, MVC is how it organizes the project, there are many questions on the subject at mvc, there are many popular frameworks that "implement" MVC, such as Laravel, but even if you use Laravel does not mean that you will use MVC, it may be that you use the framework and do something that by "logic" is not even by far MVC.
Much has been said about MVC, some examples:
Some time ago I had this doubt about "WEB" and "MVC", working with
Desktop, understand and apply MVC or other design patterns seems to me something almost intuitive, but in web the concept of direct communication "does not exist", at least it was my difficulty:
Of course, if creating a good framework will be almost straightforward communication, the question of the Web is that there are two layers, client-side and server-side, which use HTTP to communicate, so a popular Model one View is more laborious, of course the popular will actually happen indirectly, in the case of many frameworks the data is added to the Model by the Controller and returned to the Controller and then only after this are validated, overall as I said I see people using the Model more as a ORM than as anything else.
Concluding
Now I’m going to say something that is from my point of view, if you have a Model tied to a Controller, then you can only have one Model per Controller, which in my view seems a waste, or better makes the organization with MVC almost unnecessary and will probably cause code repetition, a Model should be usable for several Controllers, since the purpose of the Model is to manipulate the data and validated (supposedly)then creating a Model for each Controller would be better to create an all built-in Controllermodel even if it would still be unprofitable and cause code repetition.
Think that the Model should validate a "something", a data structure whatever and indirectly return the result (remembering that it is my opinion), if this same data structure is used in several places in the way you created your code you would either have to reuse a Controller several times or create several Models for the same thing with small variations for each situation, which would generate the repetition that I have already mentioned.
Now if you split the Model you can use more than one Model in a Controller, I know you will not always need, but there may be a situation of 2 models communicating.
I remind you again that this ending is an opinion of how to create the structure.
You see, in the structure I use, all controllers extend their respective models, where in the controller I make the business rules of a certain entity and in the model I am all part of handling data of the same. I am not discussing in itself the meaning and the role of each component of the system, but rather, based on this architecture, as would be my class diagram. Anyway, thank you very much for the reply.
– Lourençon O.
@Lourençono. what we are talking about is precisely that the concept you are using (the whole controller extending a model) does not match the MVC. If you like to program like this, fine, but the concept is not correct. Now: as for the diagram, I believe that "controller has model" in this case.
– Daniel