Разумный шаблон для класса ValidationError в C #

Question

Я собираюсь реализовать класс для представления ошибки проверки.Класс определенно будет содержать строковое значение с именем Message, которое является сообщением по умолчанию для отображения пользователю.Мне также нужен способ показать, что ошибка проверки для программиста.Идея состоит в том, что должен быть простой способ определить, произошла ли конкретная ошибка проверки.

Было бы просто реализовать строковый член с именем Type, но чтобы определить, относится ли ValidationError к этому типу, я бынужно запомнить строку, которая описывает этот тип.

if (validationError.Type == "PersonWithoutSurname") DoSomething();

Очевидно, мне нужно что-то более строго типизированное.Перечисление было бы хорошо:

if (validationError.Type == ValidationErrorType.PersonWithoutSurname) DoSomething();

Но, учитывая потенциально сотни типов ошибок проверки, я мог бы получить ужасное перечисление с сотнями значений.

Это также пришло мне в головуиспользовать подклассы:

if (validationError.GetType() == typeof(PersonWithoutSurnameValidationError)) DoSomething();

Но тогда моя библиотека классов полна сотен классов, которые в основном будут использоваться по одному разу.

Что вы, ребята, делаете?Я могу часами мучиться из-за такого рода вещей.

Ответьте тому, кто придет с предложением, которое я использую.Предложение Enum - это то, что нужно победить.

Answer 1

Я использую FluentValidation , где вы можете установить правила для каждого класса, с сообщениями по умолчанию или настраиваемыми сообщениями для каждого свойства.

Поскольку это свободная структура, вы можете комбинировать такие правила, как:

RuleFor(customer => customer.Address)
   .NotNull().Length(20, 250).Contains("Redmond")
   .WithMessage(@"Address is required, it must contain 
    the word Redmond and must be between 20 and 250 characters in length.");

Типичное использование для валидатора класса Customer:

public class CustomerValidator: AbstractValidator<Customer> {
  public CustomerValidator() {
    RuleFor(customer => customer.Surname).NotEmpty();
    RuleFor(customer => customer.Forename).NotEmpty().WithMessage("Please specify a first name");
    RuleFor(customer => customer.Company).NotNull();
    RuleFor(customer => customer.Discount).NotEqual(0).When(customer => customer.HasDiscount);
    RuleFor(customer => customer.Address).Length(20, 250);
    RuleFor(customer => customer.Postcode).Must(BeAValidPostcode).WithMessage("Please specify a valid postcode");
  }

  private bool BeAValidPostcode(string postcode) {
    // custom postcode validating logic goes here
  }
}

Customer customer = new Customer();
CustomerValidator validator = new CustomerValidator();
ValidationResult results = validator.Validate(customer);

bool validationSucceeded = results.IsValid;
IList<ValidationFailure> failures = results.Errors;  
//Bind these error messages to control to give validation feedback to user; 

Answer 2

Я серьезно не понимаю, почему у вас так много проблем ...

Если вы проверяете поля, которые вы делаете, то я обычно добавляю валидатор регулярных выражений & и обязательный валидатор полей. Для некоторых полей я добавляю собственный валидатор для своего собственного набора правил. Но это все. Для стороны клиента, а также стороны сервера. Все, что я тогда делаю, это команда page.validate, которая, если когда-либо выдает ошибку, означает, что клиентский скрипт был изменен, и я обычно перезагружаю страницу как ответ.

Также, если я хочу обработать проверку на одно значение, я использую

 System.Text.RegularExpressions.Regex.IsMatch(...

Так есть что-то еще к этому ?? Если есть, пожалуйста, укажите.

Answer 3

Если вопрос заключается в сохранении типов (особенно для того, чтобы вы могли добавлять новые), как насчет файла конфигурации в XML или в базе данных?

С app.config вы можете получить:

Что будет вызвано в коде:

//Generate the error somehow:
Validation.ErrorType = 
    ConfigurationManager.AppSettings["PersonWithoutSurnameValidationError"].Value;

//Handle the error
[Your string solution here]

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