I'm developing a web system in php, where all controllers extend their respective models, for example: I have a userController and a userModel, my question is as follows, in the precise class diagram represent the controller's methods. p>
Another doubt, my modeling methods are all protected, since controllers extend the models, is this aesthetically wrong?
Controller and Model are two different things. The Controller can inherit from another Controller base, if need be, but not from the model.
In your class diagram, the methods must be the ones that the model makes available, which the controller can or can not consume.
The Model layer represents the part of your application that business logic. This means that she is responsible to obtain the data by converting it into concepts that are significant for application, as well as processing, validating, associating and any other data processing task.
While:
The Controller layer handles the requests of the users. Is responsible for returning a response with the help of Model and View layers. link
The controller should not extend the model. The controller is at the request level ( GET , POST , PUT etc ...) and the model is concerned with data persistence (banks, normally). Here in the SO I was told of this pattern to treat the MVC called GRASP that explains well what each thing does .
Think like this: your model is not necessarily 1 to 1 with the controller. Its users model will include, change, delete users from the database, the users controller does not do any of this: it would have to decide if the user wants to log in, for example, and ask pro model to verify whether the user and password which the program received hit with some entry into the bank.
So if you make a diagram, I believe that the controller is the first point after the user's request - and his methods come in to make the decision about it - and then he delegates some pro model activity and responds with a view, take out?This idea from 1 to 1 simply does not work when the system is more "complex". For example, if you are going to register a client that has multiple addresses and phones, each one in your table. Your controller will either use instances of 3 models (clients, phones, addresses), or one of the models will use instances of the other two (clients instantiate phones and addresses to include in the database).
This is entirely relative, it does not necessarily matter how the Controller reads the Model data or how it sends data to the Model validate, what matters is that only the controller has access to the Model, so if what you have explained is exactly this
Mvc does not depend directly on programming, much less on OOP, MVC is how it organizes the project, there are many questions about it 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 might be that you use the framework and do something that by "logic" is not even MVC.
Much has already been said in the MVC site, 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, non-direct communication will be almost straightforward, the Web question is that there are two layers, client-side and server-side, which use HTTP to communicate, then a popular Model a 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, in general as I see people using the Model more like an ORM than like anything else.
Now I'll 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, this in my opinion seems a waste, or rather does the organization with MVC is almost unnecessary and will probably cause code repetition, a Model should be usable for several Controllers, since Model's purpose is to manipulate the data and validated (supposedly), so creating a Model for each Controller would be better to create a ControllerModel everything built right in, would still be unhelpful and would cause code repetition.
Think of the Model as validating a "something," any data structure whatever, and indirectly returning the result (remembering it's my opinion) if that same data structure is used in multiple places the way you created your code you would either have to reuse a Controller multiple times or create several Models for the same thing with small variations for each situation, which would generate the repetition I've already cited.Now if you split the Model you can use more than one Model in a Controller, I know you will not always need it, but there may be 2 models to communicate.
I would like to remind you that this end is an opinion on how to create the structure.
