Consider an application where adds an email address to his profile and submits it.
We have some dispute in our team over how to validate this email address. Some developers (including me) believe that we should validate this simple string via an extension method:
bool isValid = newEmail.IsEmail();
They argue that any validation mechanism other than a single method call would be overhead, and an anti-pattern (against KISS principal).
While others argue that this email should first be added to a new instance of UserEmail DTO, then that DTO should be passed to a the relevant validator:
UserEmail userEmail = new UserEmail() { Email = newEmail };
bool isValid = new UserEmailValidator().Validate(userEmail);
The second group argues that validating a single property makes no sense, because a property can’t exist on its own. Thus we should always validate an object, not a property (I mean, value type properties, like strings and integers, etc.)
What advantages and disadvantages could each approach have?
It depends on your validation rules. Checking for a correctly formatted email address can be a simple method call. Checking that an email address actually exists, or that it is not already in use somewhere else requires a larger context that usually isn’t appropriate as part of a simple field.
Where I disagree on in any case is wrapping it in a DTO instead of just passing the string straight into Validate(). If you eliminate the first line, the second solution suddenly doesn’t look so horribly complex.
Assuming that you have at least 2 tiers:
They argue that any validation mechanism other than a single method call would be overhead, and an anti-pattern (against KISS principal).
Not always true. You may need to perform validation on the client as soon as wrong data is entered without logic and data travel to the next tier. In this case, you need to validate email syntax on the client and do that again on the server (may be with further business rule such as uniqueness check).
While others argue that this email should first be added to a new instance of UserEmail DTO, then that DTO should be passed to a the relevant validator:
Say the form has 10 fields that could be in error, the user enters the email as “abc” and tabs to the next field, now do you want to alert the user? If you want to do so you have to pass the entire client object and validate it. the validator will return 10 errors back which may confuse the user since all he/she did is to tab away, no action button was pressed. Add to that the overhead of moving data across tiers and you will see that this is not quite valid.
The second group argues that validating a single property makes no sense, because a property can’t exist on its own.
This is sometimes true, however not always true. In the case of email value of “abc” or in the case of skipping a mandatory fields, you can tell that an error exists regardless of the other data entered on the form.
In summary, you must decide on the user experience style and adhere to it in all pages/forms of your application. Take in consideration that validation costs trips between tiers and may cause delay. Also, too much validation + delay in a large form is a bad thing. In all cases never relay on one tier’s validation result alone. You must do all necessary checks before committing the data to the database. Because of this, design your validation logic to be re-usable across tiers as much as possible.
The second group argues that validating a single property makes no
sense, because a property can’t exist on its own.
Just because a property can’t exist without a class doesn’t mean that an email address needs to be inside a class to be validated. An email address doesn’t need any other properties other than itself to be validated – IsEmail() looks nice and simple to me. Of course if you want to bundle together all of your validation in one place then create a validator class.