Validation on server side matching its rules


The most notable situation was how the Movies example during the training explicitly made you aware that because databases don't use NULL options, that you would need to put checks in an action to be able to stop empty values from being inserted.

Best practices is to have your server-side validation replicate your client-side validation. By default, most front-end validation frameworks consider an empty entry not a valid value to accept when requiring a field.

However, if, per chance, an empty field were to make it to the server, the server would have no problems inserting that value into the database, because as far as the DB is concerned, an empty field is valid to be inserted into a database field.

Maybe the server-side default behavior should match the client-side default behavior with no extra coding needed when possible. When a person sets a field to mandatory in an entity, they would expect a value should be enforced.

This is the by-product of a "no null" database philosophy: you create extra work that is normally understood behavior. NULL can mean something, just as much as a real value. It can mean the absence of data (and therefore something you can differentiate). It's why .NET binds empty values coming from a form as nulls to keep that record from being inserted into a table when there is no data provided on a field you NEED to have data in.

Created on 22 Jan
Comments (1)

Changed the category to Backend