Многократное использование проверки приписывает в пользовательском ViewModels
Когда я начал использовать xVal для клиентской проверки, я только реализовывал методы действия, которые использовали объекты модели предметной области в качестве viewmodel или встроили экземпляры тех объектов в viewmodel.
Этот подход хорошо работает большую часть времени, но существуют случаи, когда представление должно отобразить и отправить назад только подмножество свойств модели (например, когда пользователь хочет обновить свой пароль, но не остальную часть его данных профиля).
Одно (ужасное) обходное решение должно иметь скрытое поле ввода на форме для каждого свойства, которое иначе не присутствует на форме.
По-видимому, лучшая практика здесь должна создать пользовательский viewmodel, который только содержит свойства, относящиеся к представлению, и заполните viewmodel через Автокартопостроитель. Это намного более чисто, так как я только передаю данные, относящиеся к представлению, но это совсем не прекрасно, так как я должен повторить те же атрибуты проверки, которые уже присутствуют на объекте модели предметной области.
Идеально я хотел бы указать объект Модели предметной области как метакласс через атрибут MetaData (это также часто упоминается как "класс приятеля"), но это не работает с тех пор xVal броски, когда класс метаданных имеет свойства, которые не присутствуют на viewmodel.
Там какое-либо изящное обходное решение к этому? Я рассматривал взламывание xVal исходного кода, но возможно существует некоторый другой способ, которым я пропустил до сих пор.
Спасибо,
Adrian
Править: С прибытием ASP.NET MVC 2 это не только проблема, связанная с атрибутами проверки больше, но и это также относится к редактору и атрибутам дисплея.
4 ответа
Мы переместили нашу валидационную атрибуты на слой ViewModel. В нашем случае это все равно предоставило более чистое разделение опасений, поскольку мы тогда смогли спроектировать нашу модель домена такой, что она не может попасть в неверное состояние в первую очередь. Например, дата может потребоваться на объекте биллингации. Таким образом, мы не хотим делать это отнурительным. Но на нашем ViewModel нам, возможно, понадобится выявить нумеры, чтобы мы могли поймать ситуацию, когда пользователь не вводил значение.
В других случаях у вас может быть валидация, которая зависит от страницы / формы, и вы захотите проверить на основе команды, который пользователь пытается выполнить, а не установить кучу вещи и задавать доменную модель, «Вы действителен для попытки сделать XYZ», где при выполнении «ABC» эти значения действительны.
Я рискую по снижению и утверждению, что нет никакой выгоды для просмотра моделе (в ASP.NET MVC), особенно учитывая накладные расходы на создание и поддержание их. Если идея состоит в том, чтобы отделить от домена, это неоправданно. Уэй отделен из домена, не является пользователем для этого домена. UI должен зависит . Зависит от домена, поэтому вы либо собираетесь иметь ваши представления / действия, связанные с моделью домена, либо логику управления программами ViewModel в сочетании с моделью домена. Архитектурный аргумент, таким образом, спорный.
Если идея заключается в том, чтобы предотвратить пользователи взлома вредоносных постов HTTP, которые воспользуются возможностью привязки модели ASP.NET MVC для Mutate Pields, их нельзя разрешать изменять, то а) домен должен применять это требование, а б) Действия должны обеспечивать белые элементы обновленных свойств модели Binder.
Если вы не домен не выставляют что-то сумасшедшее, как живая, на объект памяти, вместо экземпляров, просмотра модерты потрачены впустую усилие. Итак, чтобы ответить на ваш вопрос, продолжайте проверку домена в модели домена.
Если просмотрамодели гипотетически вынуждены от вас, то я рекомендую только использовать только требования к доменам-агностическим требованиям. Это включает в себя такие вещи, как «имя пользователя, необходима», а «электронная почта отформатирована правильно».
Если вы дублируете проверку из моделей домена в моделях просмотра, то вы плотно соедините домен к пользовательскому интерфейсу. Когда изменяется проверка домена («Может применять только 2 купона в неделю», становится только «может применять только 1 купон в неделю»), UI должен быть обновлен. Вообще говоря, это было бы ужасно, и вредно для ловкости.
Если вы перемещаете валидацию из моделей домена в пользовательский интерфейс, вы по сути, вы потянули свой домен и поместили ответственность за проверку на UI. Второй интерфейс должен был бы дублировать всю проверку, и вы сочетались с двумя отдельными интерфейсами. Теперь, если клиент хочет, чтобы специальный интерфейс для администрирования инвентаризации с их iPhone проект iPhone должен копировать всю проверку, которая также находится на веб-сайте UI. Это было бы еще более ужасно, чем дублирование валидации, описанное выше.
Если вы не сможете предсказать будущее и не сможете исключить эти возможности, только проверяют доменные агностические требования.
Я не знаю, как это повлияет на проверку на стороне клиента, но если частичная проверка является вашей проблемой, вы можете изменить DataAnnotationsValidationRunner , обсуждаемый здесь, чтобы использовать IEnumerable список имен свойств, как показано ниже:
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);
}
}