С приложением MVC должна ли моя проверка бизнес-правил быть воспроизведена в модели представления и / или контроллере?

Question

Мое приложение MVC имеет четко определенную модель домена, где каждая модель выполняет свои собственные проверки бизнес-правил.

У меня вопрос: должны ли бизнес-правила быть воспроизведены также в модели представления или контроллере, или я должен просто позволить модели генерировать ошибки проверки?

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

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

Проблема с добавлением той же проверки бизнес-правил к viewmodel / controller является очевидной проблемой обслуживания дублирования, и это означает, что проверка в моей доменной модели действительно никогда не должна вызывать ошибок, что делает ее немного бессмысленной.

Как люди обычно справляются с этим?

Answer 1

Решение, которое я обычно использовал в этом сценарии, заключается в том, чтобы иметь проверку в модели (или в моем случае, как правило, в библиотеке проверки), но добавить ошибку в контроллере, которая позволяет вам отловить стандартную ошибку проверки, например:

public ActionResult Submit(String email)
{
      string errorMessage = "";

      if(Validation.IsValidEmail(email, out errorMessage))
      {
         ViewData.AddModelError("EmailAddress", "My Custom Error Message");

         //or

         ViewData.AddModelError("EmailAddress", errorMessage);
      }
}

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

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