Diagram of class MVC

Asked

Viewed 1,306 times

7

I am developing a web system in php, where all controllers extend their respective models, for example: I have a user Control and a user?.

Another question, my model methods are all protected, because the controllers extends the models, this aesthetically is wrong?.

3 answers

4

Controller and Model are two different things. Controller can inherit from another Base Controller if needed, but not from the model.

In your class diagram, the methods should be the ones that the model provides, that the controller can or cannot consume.

The Model layer (model) represents the part of your application that implements the logic of the business. This means that it is responsible for obtaining the data by converting it into concepts significant to your application, as well as processing, validate, associate and any other data processing task.

https://book.cakephp.org/2.0/pt/cakephp-overview/understanding-model-view-controller.html

While:

The Controller (controller) layer handles requests from users. You are responsible for returning an answer with the help of Model and View layers. https://book.cakephp.org/2.0/pt/cakephp-overview/understanding-model-view-controller.html

  • 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ç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.

3

The controller should not extend the model. The controller is at the request level (GET, POST, PUT etc...) and the model is concerned about data persistence (databases, usually). Here in the OS I was told about this pattern to handle the MVC called GRASP that explains well what each thing does.

Think about it: your model is not necessarily 1-to-1 with the controller. Your user model will include, change, delete users from the database, the user controller does none of this: it would have to decide whether the user wants to log in, for example, and ask the model to check if the user and password the program received match any entry in the database.

So if you make a diagram, I believe that the controller is the first point after the user’s request - and their methods go in to make the decision about that - and then it delegates some activity to the model and responds with a view, you can see?

This idea of 1 to 1 simply does not work when the system is more "complex". For example, if you are going to register a customer who has several 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 instance phones and addresses to include in the database).

  • As I commented above, I am not in doubt of the role of each component, because each platform can follow a type of pattern, my doubt is in the creation part of the class diagram, even so I appreciate the attention.

2

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 , 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.

  • 1

    Good conclusion. I think exactly like you.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.