правила проверки в MVC 3.0

Question

У меня есть одна модель представления, которая является общей для 3-4 представлений в этой модели. Я также определяю правила проверки. Теперь проблема заключается в том, что в одном из этих представлений я хочу перезаписать правила проверки модели представления для двух-трех полей.что я делаю?Я не хочу создавать новую модель представления для этого представления.

Answer 1

С точки зрения архитектуры MVC - это точно , почему вы используете модели представлений. Вы должны создать отдельные модели представления для каждого случая. Используйте automapper (доступно бесплатно в codeplex), чтобы скопировать значения между вашей моделью представления и вашей сущностью.

Даже не рассматривайте другой способ, наследование и т. Д. - вот для чего нужны ViewModels.

Answer 2

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

Answer 3

Три варианта, которые я могу придумать:

1. Создайте отдельную модель ViewModel, используя AutoMapper для обработки некоторых тяжелых работ.
2. Создайте подкласс с различными правилами проверки.
3. Создайте пользовательский ValidationAttribute, который чувствителен к контексту (либо переопределив метод IsValid(Object, ValidationContext), либо полагаясь на другую контекстную информацию из статических методов / свойств.

Например, этот обязательный атрибут проверкибудет игнорироваться, если запрос поступил с определенного URL:

public class CustomRequiredAttribute : RequiredAttribute
{
    public override bool IsValid(object value)
    {
        if (HttpContext.Current.Request.Url != "urlwhennotrequired")
            return base.IsValid(value);
        return true;
    }
}

Answer 4

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

РЕДАКТИРОВАТЬ : Я не понимаюНе согласен с ответом Тулипера, но чтобы конкретизировать мои предложения, рассмотрим сценарий, в котором вы хотите сохранить данные пользователя.Из одной формы вы создаете пользователя;с другой стороны, вы просто обновляете (это немного натянуто, но для иллюстрации).Форма «создать» может потребовать имя человека, ссылающегося на пользователя, а форма «обновление» - нет.

Используя наследование, вы можете сделать следующее:

public class SaveUserModel
{
    public int? UserId { get; set; }

    ...
}

public class CreateUserModel : SaveUserModel
{
    [Required]
    public string ReferredByName { get; set; }
}

Используя IValidatableObject, вы можете сделать это следующим образом:

public class SaveUserModel : IValidatableObject
{
    public int? UserId { get; set; }

    public string ReferredByName { get; set; }

    ...

    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        // if UserId is null, we are creating a user vs. updating
        if (UserId != null && string.IsNullOrWhiteSpace(ReferredBySiteUrl))
            yield return new ValidationResult("Please specify the name of the person who referred you.", new[] { "ReferredByName" });
    }
}

Повторюсь, яне пытаясь подтолкнуть мой ответ.Я был бы склонен повторно использовать модели, если они совершенно одинаковы в разных представлениях, но в целом достаточно различий, чтобы оправдать создание отдельных моделей.В конце концов, любой предполагаемый технический долг, уменьшенный благодаря соблюдению режима «СУХОЙ» в этой ситуации, будет чем-то вроде промывки;Модели, как правило, просты в обслуживании.