Непоследовательное поведение в методах HtmlHelper, получающих метаданные модели

Question

Я отслеживаю неожиданное поведение в MVC3, связанное с тем, как он получает метаданные модели.

Ранее я говорил с одним из моих разработчиков об использовании одного и того же EditorTemplate для некоторых данных, которые собираются в двух разных областях системы. Поля данных практически идентичны, за исключением атрибута [Обязательный]. На одной странице определенные поля обязательны для заполнения, на другой - нет. Теоретически это может быть достигнуто путем использования базовой модели, которая имеет общие атрибуты в каждом поле, и наследования этих моделей, переопределения свойств и добавления дополнительных атрибутов проверки. Например:

class BaseModel
{
    [Display(Name=”My Label”)]
    public virtual string MyLabel { get; set ;}
}

class RequiredModel : BaseModel
{
    [Required]
    public override string MyLabel { get; set ;}
}

Тогда представление может быть строго типизировано в BaseModel, и вызовы @ Html.EditorFor (m => m.MyLabel) в представлении должны подобрать правильные атрибуты, в зависимости от того, является ли фактический экземпляр модели BaseModel. или RequiredModel.

Это теория.

И на самом деле, это работает хорошо, если вы используете «старый» помощник HTML, например @ Html.TextBox ( «MyLabel»). Они вызывают ModelMetadata.FromStringExpression (field), которая правильно получает метаданные из RequiredModel, если конкретный экземпляр модели - RequiredModel. Более новые вспомогательные методы вызывают ModelMetadata.FromLambdaExpression (выражение), которое НЕ правильно получает метаданные из правильного конкретного экземпляра.

Это ошибка в MVC? Преднамеренное поведение? Есть ли обходной путь или лучший способ решения этой проблемы?

Это, конечно, тривиальный пример, фактический код, с которым мы имеем дело, имеет около 20 полей с некоторыми сложными бизнес-правилами и взаимодействием, которые одинаковы на обеих страницах, КРОМЕ для полей, обязательных для заполнения.

Answer 1

Это теория.

Нет, это не теория. По крайней мере, не мое.

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

public class UpdateViewModel
{
    [Display(Name = "My Label")]
    public string MyLabel { get; set ;}
}

и

public class CreateViewModel
{
    [Display(Name = "My Label")]
    [Required]
    public string MyLabel { get; set ;}
}

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

Очевидно, на практике я даже не удосужился выполнить проверку с использованием декларативных атрибутов DataAnnotations. Они ограничивают меня. Я использую FluentValidation.NET , который довольно элегантно решает проблемы, подобные вашей (просто определяя два разных валидатора для одной и той же модели представления - на случай, если вы решите нарушить мою теорию и использовать одну и ту же модель представления в разных просмотры).

Теперь не стесняйтесь понижать мой ответ. Я только что дал свои 2 ¢.