Well your validators are just spring beans, right, so they can be injected with the service objects that handle data access. You can have your validators get data from the database without compromising the design.
That would very much depend on how you define validation. Consider this: You're buying something, and you enter your credit card number. If the check digit does not match, you have failed validation.No transaction has been attempted.
If however, it is a valid credit card number, but it does not match your post code (DB/third party interaction required), then that is a payment error. Now consider this: You are entering your address, and you enter Mastiffica as your country. Why did the system even allow you to enter this - they should have restricted the interface to valid entries only (No DB needed post entry).
Or you enter "fifty" in the amount field of your bank payment screen. Why does it allow letters there - that fails validation (No need for DB). But you then enter 50 in the amount field, and it turns out you don't have fifty pounds in your account.
Is that a validation error? Or is it a failed transaction? Now, consider you have passed all basic entry validations (credit card checksum, country, digits, post code) and the transaction fails, because your credit card has expired.
Is that validation error, or a failed transaction? You can think of validation as a basic guarantee that users won't enter completely wild data, or you can think of validation as "I can complete this transaction with the data I have been given". I would personally favor the former, but again, it's matter of definition.
Then there's the aspect of first line validation as a security measure - wild data that has been accepted past your top UI layer can be a security risk (SQL injection, e.g. ).
No, IMHO validators should be small and side-effect free in order to allow them to be easily combined. Definitively a validator should be decoupled from persistence layer.
They shouldn't change the data, but sometimes you need to do a least an id verification. – Kathy Van Stone Jun 25 '09 at 20:07 I've heard or read this before, that's exactly why I'm asking the question. But I'm not really sure what I'm supposed to do if I don't make them able to read from a database (without side effects).
I'm kinda confused in this topic because it seems like a lot of people in the Java world share your opinion, while in Django and RoR it's perfectly normal to tie validation to the database. – Vasil Jun 25 '09 at 20:28 And exactly where do you check if username in a registration form is already given? – Janning Aug 29 at 15:33.
I checked one of mine and I'm calling the service layer from the validator: @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's 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; } }.
If you really believe in "MVC" then I don't think so, that you would want your validators to go to database. Validation is a phase which essentially validates the data from a business logic point of view. Database doesn't need to be aware of how validators will use it, nor should validators should be aware of what database is like.
That just doesn't fit in MVC model. Tomorrow if you have data coming from multiple sources, would you still go ahead and tell your validators that which source in specific it should access under what conditions. That itself will constitute logic which is not even req.In application.
The kind of validation you are looking for will be taken up as part of business objects which would ensure that before the service objects are even called; such a combination doesn't already exist. Service objects should also not contain business validations, so neither it belongs in validators nor in Service objects. But yes, if the application is small enough to not worry about too many layers a skewed approach is fine but only as long as "it is followed as a standard throughout".
In short, I feel spring validators are meant for basic validations and not really business validations.
I favor validation which is using the database beacuse of end-user usability. On submitting a registration form you want to check if the username is syntactically correct and if this username is not already given (DB access needed). The form can return with all errors at once.It can show the user all problems.
The user can fix it and send the form again. I know you can do it smarter with ajax and so on, that's not the point. I always check everything.
I check if this form is going to be handled by the upcoming transaction. If not, I get an exception because of some concurrent access which can be handled easily.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.