При использовании аннотаций данных с MVC, за и против использования интерфейса и типа метаданных - PullRequest
10 голосов
/ 30 марта 2010

Если вы прочитали эту статью о валидации с помощью валидаторов аннотаций данных , это показывает, что вы можете использовать атрибут MetadataType для добавления атрибутов валидации в свойства частичных классов. Это используется при работе с ORM, такими как LINQ to SQL, Entity Framework или Subsonic. Затем вы можете использовать «автоматическую» проверку на стороне клиента и сервера. Очень хорошо играет с MVC.

Однако мой коллега использовал интерфейс для достижения точно такого же результата. это выглядит почти точно так же, и функционально выполняет то же самое. Поэтому вместо этого:

[MetadataType(typeof(MovieMetaData))]
public partial class Movie
{
}

public class MovieMetaData
{
    [Required]
    public object Title { get; set; }

    [Required]
    [StringLength(5)]
    public object Director { get; set; }


    [DisplayName("Date Released")]
    [Required]
    public object DateReleased { get; set; }
}

Он сделал это:

public partial class Movie :IMovie
{
}

public interface IMovie
{
    [Required]
    object Title { get; set; }

    [Required]
    [StringLength(5)]
    object Director { get; set; }


    [DisplayName("Date Released")]
    [Required]
    object DateReleased { get; set; }
}

Итак, мой вопрос: когда эта разница на самом деле имеет значение?

Я думаю, что интерфейсы имеют тенденцию быть более «многократно используемыми», и что создание интерфейса для одного класса не имеет особого смысла. Вы также можете утверждать, что могли бы спроектировать свои классы и интерфейсы таким образом, чтобы вы могли использовать интерфейсы для нескольких объектов, но я чувствую, что пытаюсь приспособить ваши модели к чему-то другому, когда они действительно должны стоять самостоятельно. Что ты думаешь?

Ответы [ 3 ]

3 голосов
/ 31 марта 2010

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

2 голосов
/ 30 марта 2010

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

С другой стороны, , гораздо лучшим подходом было бы использование объектов передачи данных (DTO) для отправки данных назад и вперед, а также требования к их проверке. То есть вместо того, чтобы требовать, чтобы объект Movie удовлетворял всем требованиям валидации, вы требуете, чтобы объект MovieInput удовлетворял всем этим требованиям, а затем создаете код для сопоставления правильного MovieInput в Movie. (Если вы не хотите делать это вручную, вы можете использовать AutoMapper или другую утилиту).

Идея в основном заключается в том, чтобы иметь что-то вроде объекта View Model в пути в точно так же, как в пути в - я мог бы также позволить MovieInput называться MovieViewModel и использовать его для передачи данных как на сервер, так и за его пределы.

1 голос
/ 30 марта 2010

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

...