Is there any way to stop DataAnnotation validation after the first failure?

Question

In my ViewModels I use several DataAnnotations to validate the form data, there are usually 2-3 annotations per field.

For example a field for an email address might look like this:

[Required(ErrorMessage = "Please enter an email address.")]
[Email(ErrorMessage = "That is not a valid email address.")] // Custom
public string Email { get; set; }

Now if someone were to submit the form, both errors would show up in the validation summary. Is there any easy way to specify an order to run the validation annotations so that if the Required validation fails, the Email validation doesn't run?

If this isn't possible, how is this usually handled? Should I create custom validators for any field that has more than a single annotation? Would that be a proper way to use annotations, where a single one handles multiple types of validation?

(I'm also aware I could probably combine the Required annotation into the custom Email one, but this is just an example).

Answer 1

Ordering validation: No.

In this case you could simply remove the Required attribute because "" or " " will fail the email address validation.

And yes, AFAIK creating a custom validation attribute that combines both of them is probably your best bet.

Answer 2

The problem here is that the ordering on the attributes is completely arbitrary and decided at compile time. You actually can enforce simple ordering depending on the kind of validation runner you're using. If you are using something like xVal and a validation runner like the one mentioned here, you can add an orderby clause like this to force a specific kind of attribute to sort to the top:

orderby attribute.GetType() == typeof(T) ? 0 : 1

Just make a strongly-typed validation runner method, where T is derived from the ValidationAttribute class.

Answer 3

In this specific case I would probably take the same approach that the ASP.NET WebForms validators take - simply have the EmailAttribute validator return true if the value is null or empty.

Think about it:

• If the e-mail address is required, then there will also be a [Required] validator and a null/empty e-mail address will generate a validation error anyway;

• If the e-mail address is optional, a null/empty value should be considered valid.

No need to solve the complex problem of intercepting validators when you can just design the individual validators to play nice together!