Procedures after errors should be in the services / validations or in the controller?

Question

Procedures after errors should be in the services / validations or in the controller?

Navigation

#1 by (3 votes)

2

In a backend that has separate validation functions to verify the validity of the data, if this data is invalid the procedure (returning a 400 or printing something on the screen, for example) must occur in this validation part or is a task for the controller?

In the frontend where I have a part that takes care of the requests to the server (services), when an error of one of these requests is received, is the service or controller responsible for the user?

Whose responsibility?

simple example with php (the question is not focused on any language, just for example)

main.php:

//Forma 1
isValidPassword("123", "321");

//Forma 2
isValidPassword("123", "321") or die("senhas diferente");

validation.php:

//Forma 1
function isValidPassword($password, $confirm) {
    $password === $confirm or die("senhas diferente");
}

//Forma 2
function isValidPassword($password, $confirm) {
    return $password === $confirm;
}

In front of the idea is the same, execute a alert() on the controller or the validation function?

controller services

asked by anonymous 22.07.2018 / 00:56

1 answer

How not to activate js inherited function? Shadow in svg - CSS

score 3 · Accepted Answer

Point of View of Code Quality

From the point of view of the quality of the code, it should use form 2. The reason arises from two questions that I, a programmer who inherited his code for maintenance, for example, will consider only the name of his function without looking at her code):

What do I expect your isValidPassord function to do?

What do I expect your isValidPassord function to return?

Well, by her name, I hope she checks that the password is valid and returns true if it is valid and false otherwise. In form 1, the function does more than that. It closes the script if the password is not valid, and this may be behavior considered unexpected by someone "reading" the code.

Is it wrong? No. Is it desirable? Also, because this kind of thing (mainly accumulated in large projects) will make it difficult for you to work and leave your colleagues or yourself (experience shows this, my dear).

Viewpoint of UX

From the point of view of UX, validations should be made in the FrontEnd whenever possible. The reason is because so a user error can be communicated much more quickly, without it having to wait for communication with the server. This is not usually the case with password validation or other things that require querying a database, but it is the case of CPF validations, data formats, etc. See I said "whenever possible".

Architecture Viewpoint

It's a good idea to separate validation from any action other than it (business rules, for example) because you make the services (and I'm generally using validation can also be a service) more atomized and reusable. The atomization, by the way, facilitates the testing and assurance that a change in a function X that uses the validation V will not break that another function Y that eventually also uses this V validation.