Is it better to check for allowed domain values on the frond end or let the database engine handle the domain integrity. For example If you have a data entry form for employee, is it better to check for allowed values on the data entry form before submitting the data to the database assuming network IO is not a big issue. What if there are lots of checks to be performed, would the engine be faster or would checking the value on the front end take the load of the dB engine?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
It is best to have checks in both places.
Have checks on the client side in order to give direct feedback to the client without having to roundtrip to the server.
Have checks on the server side because you can't trust the client (you never know if data has been spoofed, someone hacked your UI or whatever).
To me, the best place to check it is in two places. First on the UI (presentation layer), make sure the data entered meets the very basic requirements. For example, a user has to enter a date in a text box, the presentation layer would make sure the value entered is in fact a date.
The second place would be the service layer, or depending on your architecture, the business layer. The data entered in the UI would be placed into an object and sent down to the service layer (or business layer), which would enforce the business rules. For example, the date entered has to be after the current day. Other types of validation can occur here as well, no duplicate entries, and so on.
Once the data has been validated by the service layer then it will send it down to the repository (or data access layer) to be inserted into the database. I am not a real big fan of putting validation on the database. Mostly because it is next to impossible to unit test properly. The type of validation done on a database should really be limited to ensure foreign key integrity or unique indexes.