Повторное использование атрибутов проверки в пользовательских ViewModels

Это основная причина, по которой ваши экраны ввода не должны быть тесно связаны с вашей моделью. Этот вопрос на самом деле всплывает здесь, в теге MVC, примерно 3-4 раза в месяц. Я бы обманул, если бы смог найти предыдущий вопрос, и некоторые комментарии здесь интересны. ;)

Проблема, с которой вы столкнулись, заключается в том, что вы пытаетесь объединить два разных контекста проверки модели в одну модель, которая терпит неудачу при большом количестве сценариев. Лучший пример — регистрация нового пользователя, а затем администратор отредактирует поле пользователя позже. Вам необходимо подтвердить пароль для объекта пользователя во время регистрации, но вы не будете показывать поле пароля администратору, редактирующему данные пользователя.

Все варианты обхода неоптимальны. Я работал над этой проблемой для трех проектов, и реализация следующих решений никогда не была чистой и обычно разочаровывающей. Я постараюсь быть практичным и забыть все обсуждения DDD/db/model/hotnessofthemonth, которые ведут все остальные.

1) Множественные модели просмотра Наличие почти одинаковых моделей просмотра нарушает принцип DRY, но я считаю, что затраты на этот подход очень низкие. Обычно нарушение DRY увеличивает затраты на техническое обслуживание, но ИМХО затраты на это самые низкие и невелики. Гипотетически говоря, вы не меняете максимальное количество символов в поле LastName очень часто.

2) Динамические метаданные В MVC 2 есть хуки для предоставления ваших собственных метаданных для модели. При таком подходе вы можете использовать все, что вы используете для предоставления метаданных, исключая определенные поля на основе текущего HTTPRequest и, следовательно, Action и Controller. Я использовал этот метод для создания системы разрешений на основе базы данных, которая обращается к базе данных и сообщает подклассу DataAnnotationsMetadataProvider, чтобы исключить значения на основе свойств, хранящиеся в базе данных.

Этот метод отлично работает, но единственная проблема заключается в проверке с помощью UpdateModel(). Чтобы решить эту проблему, мы создали метод SmartUpdateModel(), который также обращается к базе данных и автоматически генерирует массив exclude string[], чтобы любые недопустимые поля не проверялись. Мы, конечно, кэшировали это из соображений производительности, так что это неплохо.

Просто хочу повторить, что мы использовали [ValidationAttributes] в наших моделях, а затем заменили их новыми правилами во время выполнения. Конечным результатом было то, что поле [Required] User.LastName не проверялось, если у пользователя не было разрешения на доступ к нему.

3) Сумасшедший интерфейс с динамическими прокси-вещами Последним методом, который я пробовал, было использование интерфейсов для ViewModels. Конечным результатом было то, что у меня был объект User, унаследованный от таких интерфейсов, как IAdminEdit и IUserRegistration. И IAdminEdit, и IUserRegistration будут содержать атрибуты DataAnnotation, которые выполняют все проверки, зависящие от контекста, такие как свойство Password с интерфейсами.

Это требовало некоторого хакерства и было скорее академическим упражнением, чем чем-либо еще. Проблема со 2 и 3 заключается в том, что UpdateModel и провайдер DataAnnotationsAttribute нужно было настроить, чтобы узнать об этом методе.

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

Теперь я понимаю, что это очень специфичный для xVal вопрос, но все пути к динамической проверке, подобные этому, ведут к настройке внутренних поставщиков метаданных MVC. Поскольку все метаданные являются новыми, на данный момент нет ничего такого чистого или простого. Работа, которую вам придется проделать для настройки поведения проверки MVC, несложна, но требует глубоких знаний о том, как работают все внутренние компоненты.

Мы переместили наши атрибуты проверки на слой ViewModel. В нашем случае это в любом случае обеспечило более четкое разделение проблем, поскольку мы смогли спроектировать нашу модель предметной области таким образом, чтобы она изначально не могла попасть в недопустимое состояние. Например, Date может потребоваться для объекта BillingTransaction. Поэтому мы не хотим делать его Nullable. Но в нашей ViewModel нам может понадобиться выставить Nullable, чтобы мы могли поймать ситуацию, когда пользователь не ввел значение.

В других случаях у вас может быть проверка, специфичная для каждой страницы/формы, и вы захотите проверить на основе команды, которую пытается выполнить пользователь, а не задавать кучу вещей и спрашивать модель домена: «Вы действительно для попытки сделать XYZ», где при выполнении «ABC» эти значения действительны.

Если вам гипотетически навязывают ViewModels, я рекомендую применять только требования, не зависящие от предметной области. Это включает в себя такие вещи, как «требуется имя пользователя» и «электронная почта отформатирована правильно».

Если вы дублируете проверку моделей предметной области в моделях представления, то вы тесно связываете предметную область с пользовательским интерфейсом. При изменении проверки домена («можно применять только 2 купона в неделю» становится «можно применять только 1 купон в неделю»), необходимо обновить пользовательский интерфейс. Вообще говоря, это было бы ужасно и пагубно для ловкости.

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

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

Я не знаю, как это повлияет на проверку на стороне клиента, но если частичная проверка является вашей проблемой, вы можете изменить DataAnnotationsValidationRunner, обсуждаемый здесь, чтобы принять IEnumerable<string> список имен свойств, как показано ниже:

public static class DataAnnotationsValidationRunner
{
     public static IEnumerable<ErrorInfo> GetErrors(object instance, IEnumerable<string> fieldsToValidate)
     {
           return from prop in TypeDescriptor.GetProperties(instance).Cast<PropertyDescriptor>().Where(p => fieldsToValidate.Contains(p.Name))
                  from attribute in prop.Attributes.OfType<ValidationAttribute>()
                  where !attribute.IsValid(prop.GetValue(instance))
                  select new ErrorInfo(prop.Name, attribute.FormatErrorMessage(string.Empty), instance);
     }
}

Я собираюсь рискнуть отрицательными голосами и заявить, что нет никакой пользы от ViewModels (в ASP.NET MVC), особенно с учетом накладных расходов на их создание и поддержку. Если идея состоит в том, чтобы отделиться от домена, это неоправданно. Пользовательский интерфейс, отделенный от домена, не является пользовательским интерфейсом для этого домена. Пользовательский интерфейс должен зависеть от домена, поэтому либо ваши представления/действия будут связаны с моделью предметной области, либо ваша логика управления ViewModel будет связана с моделью предметной области. Аргумент об архитектуре, таким образом, спорный.

Если идея состоит в том, чтобы запретить пользователям взламывать вредоносные HTTP-запросы POST, которые используют привязку модели ASP.NET MVC для изменения полей, которые им не должно быть разрешено изменять, то A) домен должен применять это требование, и B) действия должны предоставлять белые списки обновляемых свойств для связывателя модели.

Если ваш домен не предоставляет что-то сумасшедшее, например, живой граф объектов в памяти вместо копий сущностей, ViewModels — это напрасная трата усилий. Итак, чтобы ответить на ваш вопрос, сохраните проверку домена в модели домена.