Checking parameters in MVC

4

In the MVC Standard, the Model is responsible for the business layer, in which will be the business rules and validations. I have a question about the following. A method in the controller that receives any parameter (it 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 Model expect the parameter to be correct? That is, should there be a validation in the controller to know if the parameter came correctly or should you pass the parameter to the Model as it was sent to the controller and the Model must do this validation?

The second doubt: if the Model does parameter validation how should the return be handled? Let's say the action is to insert a new entity into the database. And the default is to return the ID of this entity on success. In case of error, what would be the best decision, return 0 as an error, throw an exception and return 0, or would it be better to refactor these actions so that they return something that can be used both on success and on return? / p>

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

    
asked by anonymous 22.02.2015 / 21:51

2 answers

5

The model must take care, among other things, of its own integrity. It should do the validation 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 corrected in some way by the user. What to do with the error is not the model's responsibility.

Responding to questions:

The first question: should Model expect the parameter to be correct? That is, should there be a validation in the controller to know if the parameter came correctly or should you pass the parameter 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 Model validates the parameter how should the return be handled? Let's say the action is to insert a new entity into the database. And the default is to return the ID of this entity on success. In case of error, what would be the best decision, return 0 as an error, throw an exception and return 0, or would it be better to refactor these actions so that they return something that can be used both on success and on return? / em> Failing to attempt to save, the model must return enough information for the controller to handle the error. Returning false and an / json object with the attributes that failed validation is a good alternative.

Embrace

    
23.02.2015 / 01:24
3

There are many ways to do it.

I'm going to analyze a possibility following the @Adriano Godoy proposal, not that it's wrong, but it's just simplistic considering a bool return in case of failure or success. Read that it is not a criticism, but a complement to the answer given .

  

In practice, model receives 123 in the name field, and checks that it is not an input type AZ and returns false. Your controller will receive bool as an error and warn the view that the input is incorrect. The problem here would be to report the error to the user, assuming you want to display a message like: Your name should contain only letters . Your template has validated and returned false , but does not report 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 it starts to lose the pattern.

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

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

All my validation and sanitization are done by the controller and in case of failure nor 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 different input formats). But this is the my case and several factors were taken into account, but something simpler can be done as described above.

The second case is another standard. Some people only use exception for error handling. I think 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.

    
23.02.2015 / 03:33