Parameter check on MVC

Asked

Viewed 257 times

4

In the MVC Standard, the Model is responsible for the business layer, in it will be the business rules and validations. I have a question about the following. A method in the controller that takes any parameter (can be a primitive type or an object). It calls the model to perform an action (such as persisting in the database, changing or deleting).

The first question: should the Model wait for the parameter to be correct? That is, there must be a validation in the controller to know if the parameter came correctly or the parameter must be passed to the Model as it was sent to the controller and the Model must do this validation?

The second question: if the Model validates the parameter how should the return be treated? Let’s say the action is to insert a new entity into the database. And that the default is to return that entity’s ID in case of success. In case of error, which would be the best decision, return 0 as an error, launch an Exception and return 0 or it would be better to refactor these actions so that they return something that can be used both in case of success and in case of return?

I am working on a project made in Silex with Doctrine DBAL, but that was not done by me and I am having these doubts because I see that the application does not follow a correct and standardized flow in these situations. Right here the controller has more responsibility than the Model and this has made me evaluate the refactoring.

2 answers

5


The model must take care, among other things, of its own integrity. It must validate and return the error when a save() method is invoked, for example. The most common is that when trying to save a model with validation error, it returns a Boolean (true/false).

It will be up to the controller to forward this error so that it is somehow corrected by the user. What to do with the error is not the responsibility of the model.

Answering to the questions:

The first question: should the Model wait for the parameter to be correct? That is, there must be a validation in the controller to know if the parameter came correctly or the parameter must be passed to the Model as it was sent to the controller and the Model must do this validation? No. You must pass the parameter as it was sent, the Model does the validation and returns to the controller so that the error is "forwarded".

The second question: if the Model validates the parameter how should the return be treated? Let’s say the action is to insert a new entity into the database. And that the default is to return that entity’s ID in case of success. In case of error, which would be the best decision, return 0 as an error, launch an Exception and return 0 or it would be better to refactor these actions so that they return something that can be used both in case of success and in case of return? When failing to save, the model should return enough information so that the controller can handle the error. Returning false and a/json object with the attributes that failed validation is a good alternative.

hug

  • Thanks Adriano. But I could edit your answer more clearly. Like, following a little my doubts. I realized that the model should be independent but it was not completely clear the answers to my questions.

  • Edited ;) Colleague @Papa Charlie’s response can help you more in implementing the solution. hug

  • Thank you @Adriano-Godoy. It’s clearer now!

3

There are many ways to do it.

I will analyze a possibility following @Adriano Godoy’s proposal, not that it is wrong, but it is just simplistic taking into account a bool return in case of failure or success. It is not a criticism, but a complement to the answer given.

In practice the model receives 123 in the field name, and checks that it is not a type input AZ and returns false. Your controller will receive the bool as error and warn on view that the input is incorrect. The problem here would be how to report the error to the user, assuming you want to show a message of type: Your name must contain only letters. Your model has validated and returned false, but does not specify the type of error found.

1) You could work with a return in array form: array( 'status' => false , 'campo_nome' => 'Seu nome deve conter apenas letras' ), but thus begins to lose the pattern.

2) If your model works with an instance of a Validate, the controller could receive the object and work the error messages.

$model-> validate-> status = false, your controller would have access to error messages relevant to form fields, for example, and would switch to the view without major problems.

All mine Validation and sanitization are done by the controller and in case of failure do not even invoke the model. My rules are abstracted from the model precisely to facilitate validations and messages in the case of internationalization and regionalization (taking into account the different input formats). But this is the mine case and various factors have been taken into account, but something simpler can be done as described above.


The second case is more of a pattern. There are those who only use the exception for error handling. I judge that exception can be used for flexibility. If you work with them correctly there will be no problem. But there are cases that a simple bool resolves.

  • Thank you Papa Charlie. Your reply was enlightening!

Browser other questions tagged

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