Есть ли способ остановить проверку DataAnnotation после первого сбоя?

Question

В моих ViewModels я использую несколько аннотаций данных для проверки данных формы, обычно в каждом поле есть 2-3 аннотации.

Например, поле для адреса электронной почты может выглядеть так:

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

Теперь, если кто-то отправит форму, обе ошибки будут отображаться в сводке проверки. Есть ли простой способ указать порядок для запуска аннотаций проверки, чтобы в случае сбоя обязательной проверки проверка электронной почты не выполнялась?

Если это невозможно, как это обычно делается? Должен ли я создавать собственные валидаторы для любого поля, содержащего более одной аннотации? Будет ли это правильным способом использовать аннотации, когда один обрабатывает несколько типов проверки?

(я также знаю, что, возможно, я мог бы объединить аннотацию Required в пользовательскую аннотацию Email, но это только пример).

Answer 1

Проблема здесь в том, что упорядочение атрибутов является совершенно произвольным и определяется во время компиляции. На самом деле вы можете применять простое упорядочение в зависимости от типа используемого валидатора проверки. Если вы используете что-то вроде xVal и средство проверки правильности, такое как упомянутое здесь , вы можете добавить предложение orderby, подобное этому, чтобы принудительно отсортировать атрибуты определенного вида:

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

Просто создайте строгий тип метода проверки правильности, где T является производным от класса ValidationAttribute.

Answer 2

В этом конкретном случае я бы, вероятно, использовал тот же подход, что и валидаторы ASP.NET WebForms - просто верните валидатор EmailAttribute, возвращающий true, если значение null или пусто.

Подумайте об этом:

• Если требуется адрес электронной почты, то также будет иметься валидатор [Required], и нулевой / пустой адрес электронной почты в любом случае вызовет ошибку проверки;

• Если адрес электронной почты не является обязательным, нулевое / пустое значение следует считать действительным.

Нет необходимости решать сложную проблему перехвата валидаторов, когда вы можете просто спроектировать отдельные валидаторы, чтобы они хорошо играли вместе!

Answer 3

Подтверждение заказа: №

В этом случае вы можете просто удалить атрибут Required, поскольку "" или "" не пройдут проверку адреса электронной почты.

И да, AFAIK, создание пользовательского атрибута проверки, который объединяет их обоих, вероятно, является лучшим выбором.