Какие существуют подходы к отображению сообщений проверки, которые возникают в бизнес-слое, для отображения в контекстной области на уровне презентации?

57
6

В моем слое представления, когда пользователь хочет внести изменения, структура mvc отображает их запрос в ViewModel. Затем я сопоставляю эту viewmodel с DTO и передаю этот DTO на мой бизнес-уровень. Я запускаю проверки против этого DTO, а затем, когда возникают ошибки проверки, я бросаю исключение ValidationException. Мой уровень представления улавливает это ValidationException и покажет эти сообщения проверки в сводном представлении в верхней или нижней части представления. Я предпочел бы вместо этого показывать эти сообщения проверки рядом с элементами управления, в которых они тоже ссылаются, поэтому пользователь имеет лучшую обратную связь о том, что нужно исправлять.

Мои попытки решить эту проблему заключались в атрибуте свойств ViewModel с помощью настраиваемого атрибута, который позволил мне отправлять сообщения о проверке карты, которые возникли из DTO, в свойства на моей модели viewmodel. Таким образом, бизнес-уровень создавал бы такие сообщения проверки:

if (personDto.FirstName == "Evan") {
validationMessages.add("FirstName", "You cannot be Evan");
}

Моя модель просмотра имела бы атрибуты:

public class PersonViewModel {
[HandlesValidation("FirstName")]
public string FirstName {get;set;}
}

Таким образом, я мог поймать сообщения проверки на уровне презентации и узнать, где их сопоставить в представлении.

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

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

Кто-нибудь еще придумал какие-либо изящные решения этой проблемы?

спросил(а) 2013-12-30T19:17:00+04:00 6 лет, 8 месяцев назад
1
Решение
69

Я вроде соглашусь с комментарием @Chris Pratt, но также не согласен с этим. Я считаю, что правила проверки представляют собой бизнес-знания и, следовательно, относятся к бизнес-уровню.

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

Один из лучших способов сделать это заключается в том, что ваш бизнес-уровень DTO двойной как ваш viewmodels. Однако это не всегда возможно, или даже желательно. Если вы используете FluentValidation.NET для проверки на своем бизнес-уровне, есть несколько альтернатив. Если вы подключите FV.NET к проекту MVC, вы можете сначала выполнить те же правила проверки с вашей моделью просмотра. Например:

public class SomeBusinessCommand
{
public string PropertyX { get; set; }
}

public class SomeBusinessValidator : AbstractValidator<SomeBusinessCommand>
{
public SomeBusinessValidator()
{
RuleFor(x => x.Property1).NotEmpty().MustMeetSomeBusinessRequirement();
}
}

public class SomeViewModel // assume this maps to SomeBusinessCommand
{
public string PropertyX { get; set; }
}

public class SomeViewValidator : AbstractValidator<SomeViewModel>
{
public SomeViewValidator()
{
RuleFor(x => x.Property1).NotEmpty().MustMeetSomeBusinessRequirement();
}
}

Теперь я знаю, что вы собираетесь посмотреть на это и сказать, что это не сухо. Это похоже на правду. Как я уже сказал, это может быть полностью сухим, если вы используете свой бизнес DTO как свои модели просмотра. Однако даже при таком подходе мы достигаем некоторых уровней повторного использования. Например, оба валидатора могут использовать один и тот же файл resources.resx для получения сообщений проверки. Кроме того, валидация MustMeetSomeBusinessRequirement живет в вашем бизнес-слое, но повторно используется как для бизнес-так и для презентационных слоев.

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

ответил(а) 2013-12-30T19:54:00+04:00 6 лет, 8 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема