Should validators in spring access the database?

Question

I am not sure if this is a good design decision to force validators to check commands based on the state of the database. For example, if I need to check the User bean, in addition to checking that the mail and username are empty, etc. I also need to reject the values ​​if they are already in use. Should this logic go in validators or service objects?

Answer 1

Well, your validators are just spring beans, so they can be injected with service objects that handle data access. You can force your validators to retrieve data from the database without sacrificing design.

Answer 2

This will greatly depend on how you define validation. Consider this: you are buying something, and you enter your credit card number. If the check digit does not match, you have not passed the test. No transaction was attempted. If, however, this is a valid credit card number, but it does not match your postal code (requires interaction with the database / third party), then this is a payment error.

Now consider this: you enter your address, and you enter Mastiffica as your country. Why the system even allows you to enter this - they had to restrict the interface to only valid entries (no blog entry needed).

Or you enter “fifty” in the quantity field of your bank payment screen. Why it allows you to write letters - this does not allow you to perform a check (there is no need for a database). But then you enter 50 in the quantity field, and it turns out you do not have fifty pounds in your account. Is this a validation error? Or is this a failed transaction?

Now, consider that you went through all the basic input checks (credit card checksum, country, numbers, zip code), and the transaction failed because your credit card has expired. Is this validation error or failed transaction?

You can think of verification as the main guarantee that users will not enter completely wild data, or you can think of verification as "I can complete this transaction with the data that was provided to me." I would personally approve the first, but again, this is a matter of definition.

Then there is the aspect of checking the first line as a security measure - wild data that was taken behind the upper level of the user interface can pose a security risk (for example, SQL injection).

Answer 3

no, IMHO validators should be small and a side effect so that they can be easily combined. Finally, the validator must be disconnected from the save level.

Answer 4

I checked one of mine and I call the service level from the check:

@Service public final class StartFormValidator { private FacilityService facilityService; private AdminService adminService; /** * Verify that they've selected a facility. Verify that they've selected a * valid facility. Verify that they've selected a view and that it a valid * view. * * @param startForm * @param errors * @return true if no errors were set */ public boolean isValid(final StartForm startForm, final Errors errors) { if (startForm.getFacilityId() == 0) { errors.rejectValue("facilityId", "facilityIdEmpty", "Select a facility."); } if (!this.facilityService.isFacilWaitlistEnabled(startForm .getFacilityId())) { errors.rejectValue("facilityId", "facilityInvalid", "Invalid facility"); } if (StringUtils.isBlank(startForm.getPassword())) { errors.rejectValue("password", "passwordEmpty", "Enter the password."); return (false); } if (!this.adminService.validateAdmin(startForm.getPassword())) errors.rejectValue("password", "passwordInvalid", "Incorrect password"); return (!errors.hasErrors()); } /** * @param _facilityService */ @Autowired public void setFacilityService(final FacilityService _facilityService) { this.facilityService = _facilityService; } /** * @param _adminService */ @Autowired public void setAdminService(final AdminService _adminService) { this.adminService = _adminService; } 

}

Answer 5

If you really believe in "MVC", then I don’t think that you want your validators to go to the database. Validation is the phase that basically validates data in terms of business logic.

The database does not have to know how the validators will use it, and it does not need to know what the database is. It just doesn't fit the MVC model. Tomorrow, if you have data coming from several sources, do you continue and tell your validators which source in a particular case it should access under what conditions. This in itself will be logic that does not even require. in the application.

The type of validation you are looking for will be considered as part of the business objects that ensure that before the service objects are even called; such a combination does not yet exist.

Service objects should also not contain business checks, so they should not be used in validators or service objects. But yes, if the application is small enough not to worry about too many layers, the distorted approach is fine, but only as long as "it is respected as a standard in everything."

In short, I believe that spring validators are for core validations, not business validation.

Answer 6

i supports validation, which uses a database for ease of use by the end user.

When submitting the registration form, you want to check if the username is syntactically correct and if this username has not yet been specified (access to the database is required).

A form may return with all errors at the same time. It can show the user all the problems. The user can correct it and submit the form again.

I know that you can do it smarter with ajax etc., this is not the main thing.

I always check everything. I check to see if this form will be processed by the upcoming transaction. If not, I get an exception due to some concurrent access that can be easily handled.