Как получить пользовательский контроль над функцией проверки аннотаций данных в ASP.NET MVC 2 с использованием LinqToSQL?

Question

Я использую LinqToSQL, создавая свои сущности с помощью дизайнера в студии, который прекрасно создает класс конструктора со всеми соответствующими классами сущностей. Обычно, когда я хотел, чтобы к моим сущностям добавлялись какие-то нестандартные вещи, я создавал частичный класс и делал там нестандартные вещи. Вот моя проблема; новый ASP.NET MVC 2 (предварительный просмотр) содержит хорошую поддержку для проверки аннотаций данных, которая позволяет выполнять следующие действия:

public class Customer 
{
    [Required(ErrorMessage = "Name is Required")]
    public string Name { get; set; }
}

Кто-нибудь может мне посоветовать, как с этим справиться? Я надеялся не создавать дополнительный класс и делать какие-то сопоставления .. :( И было бы неплохо сохранить проверку моих сущностей в моих сущностях:)

Я надеюсь, что здесь есть какой-то смысл ... заранее спасибо.

Answer 1

Я столкнулся с этой проблемой с MVC V1 и xVal. Я закончил тем, что использовал «классы друзей», как подробно описано здесь Schotime (кеш Google, так как у него проблемы с сайтом).

Это прекрасно работает для меня, но я не знаком с методом MVC v2, позволяющим узнать, будут ли его подпрограммы «подбирать» метаданные в ваших классах друзей.

Трудно спорить с кем-то, кто начинает с того, что "у всех свое мнение", но я не хотел бы модифицировать сгенерированные файлы для LINQ. Я вижу смысл в скаффолде, но когда я нахожусь в разработке, я делаю так много изменений в моей базе данных (и отношениях), что часто отбрасываю класс и воссоздаю, перетаскивая таблицу обратно. Иногда я удаляю все классы и перетаскиваю всю базу данных. С другой стороны, я предполагаю, что это свидетельствует о плохом планировании с моей стороны.

Answer 2

Если я использую LinqToSQL для генерации класса, я всегда создаю облегченную версию класса контейнера данных с постфиксом Data. Затем я использую этот класс для передачи данных на клиент / сервер.

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

Скажем, LinqToSql предоставляет вам класс Car с int id, int doors, string string, int wheel, основанными на столе Cars. Я бы создал

public class CarData
{
    [Required(ErrorMessage = "ID is Required")]
    public int id { get; set; }

    [Required(ErrorMessage = "doors are Required")]
    public int doors { get; set; }

    [Required(ErrorMessage = "color is Required")]
    public string color { get; set; }

    [Required(ErrorMessage = "wheels are Required")]
    public int wheels { get; set; }
}

Вы можете даже использовать linq, чтобы выбрать новый из них через

var myCar = 
     from c in MyDataContext.Cars 
     where c.id == 1 
     select new CarData()
     { 
          id = c.id, 
          doors = c.doors, 
          color = c.color, 
          wheels = c.wheels 
     };

Вы также сохраните linq to sql функциональность отложенного выполнения вместе с этим. В любом случае, вы бы добавили эти атрибуты в этот класс «Данные» (как показано), чтобы у вас был специализированный легкий класс, который легко сериализуется и имеет все нужные вам атрибуты проверки.

Answer 3

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

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

Answer 4

Спасибо, что поделились своей точкой зрения на это. Я думал об этом, но не уверен, хочу ли я этого.

Решением, которое я сам придумал, было сделать все мои сгенерированные сущности абстрактными, а все мои свойства виртуальными, например, присвоив им имя DBCustomer, и создать унаследованный класс Customer. Затем переопределяем все свойства и вызываем base.PropertyName в методах получения и установки. Что вы думаете об этом?