Проверка формы веб-приложения - дизайн для распространения ошибок домена на стороне клиента?

Ответ 1

Хотя не тот же вопрос, что и этот, я думаю, что ответ тот же:

Инкапсулировать логику проверки в класс многократного использования. Эти классы обычно называются спецификациями, валидаторами или правилами и являются частью домена.

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

Если ваш пользовательский интерфейс использует ту же технологию, что и модель, вы также можете использовать там спецификации (например, при использовании NodeJS на сервере вы можете писать спецификации в JS и использовать их в браузере, слишком).

Изменить - дополнительная информация после чата

• Создавайте мелкозернистые спецификации, чтобы вы могли отображать соответствующие сообщения об ошибках, если сбой спецификации.
• Не вводите бизнес-правила или спецификации в поля формы.
• Создавайте спецификации для бизнес-правил, а не для основных задач проверки ввода (например, для проверки на нуль).

Ответ 2

Я хочу использовать подход, используемый нами в одном проекте DDD.

• Мы создали BaseClass с полями ErrorId & ErrorMessage.

• Каждый DomainModel получается из этого BaseClass и, следовательно, имеет два дополнительных поля ErrorId и ErrorMessage, доступные из BaseClass.

• Всякий раз, когда возникает исключение, мы обрабатываем исключение (регистрируемся на сервере, предпринимаем соответствующие шаги для компенсации логики и извлекаем сообщение "Удобное для пользователя" из локализованного файла ресурсов локализации клиента для сообщения), а затем распространять данные как простой поток без исключения исключения или исключения.

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

Это простой простой подход, который мы выполнили с момента запуска проекта.

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

Для проверки на каждом уровне поля используйте Блок приложений проверки из Корпоративной библиотеки.

Его можно использовать как:

Украсить свойства модели домена соответствующими атрибутами:

public class AttributeCustomer 
{
    [NotNullValidator(MessageTemplate = "Customer must have valid no")]
    [StringLengthValidator(5, RangeBoundaryType.Inclusive, 
        5, RangeBoundaryType.Inclusive, 
        MessageTemplate = "Customer no must have {3} characters.")]
    [RegexValidator("[A-Z]{2}[0-9]{3}", 
    MessageTemplate = "Customer no must be 2 capital letters and 3 numbers.")]
    public string CustomerNo { get; set; }
}

Создайте экземпляр проверки, например:

Validator<AttributeCustomer> cusValidator = 
            valFactory.CreateValidator<AttributeCustomer>();

Использовать объект и выполнить проверку как:

customer.CustomerNo = "AB123";
customer.FirstName = "Brown";
customer.LastName = "Green";
customer.BirthDate = "1980-01-01";
customer.CustomerType = "VIP";

ValidationResults valResults = cusValidator.Validate(customer);

Проверьте результаты проверки как:

if (valResults.IsValid)
{
    MessageBox.Show("Customer information is valid");
}
else
{
    foreach (ValidationResult item in valResults)
    {
        // Put your validation detection logic
    }
}

Пример кода берется из Microsoft Enterprise Library 5.0 - Введение в блок проверки Эти ссылки помогут понять блок Application Validation:

http://www.codeproject.com/Articles/256355/Microsoft-Enterprise-Library-Introduction-to-V

https://msdn.microsoft.com/en-in/library/ff650131.aspx

https://msdn.microsoft.com/library/cc467894.aspx