Linq2SQL question

Question

Hello, I'm using LinqToSQL, creating my entities with the designer in studio which nicely creates the designer class with all corresponding entity-classes. Normally when I wanted some custom stuff added to my entities, I would create a partial class and do the custom stuff there. Here's my problem; the new ASP.NET MVC 2 (preview) contains some nice Data Annotation Validation support, which allows you to do something like:

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

Can anybody advise me how to handle this? I was hoping not to create an extra class and do some sort of mapping.. :( And it would be nice to keep the validation of my entities in my entitities :)

I hope I'm making some sense here.. thanks in advance.

Jeroen.

Answer 1

Everyone has a different opinion but I am the kind of guy who goes ahead and edits generated files. If I can add a partial class then I will but for cases like this I would go ahead and edit the property in the generated file.

A lot of generated files should be treated as a scaffold that is yours once the generator has spit it out. Once you start thinking about it that way some things can become a lot easier. By the way I wouldn't advocate this approach for a file that is going to be regenerated often as that would create many more headaches.

Answer 2

Hi Andrew,

Thank you for sharing your point of view on this. I thought about that, but I'm not sure if I want that.

The solution I came up myself was making all my generated entities abstract, and all my properties virtual, naming them "DBCustomer" for instance, and creating an inherited "Customer" class. Then overriding all properties, and call base.PropertyName in the getters and setters. What do you think about that?

Answer 3

if I use LinqToSQL to generate a class, I always create a lightweight data container version of the class with a postfix of Data. I then use that class to transfer data to / from the client / server.

I may not be describing this perfectly but I believe it is somewhat common practice.

Say LinqToSql gives you a Car class with an int id, int doors, string color, int wheels based off the Cars table. I'd create

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; }
}

You can even use linq to select a new one of these via

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 
     };

You'll even retain linq to sql's delayed execution functionality with this as well. Anyway, you would add those attributes to this "Data" class (as shown), that way you have a specialized lightweight class that serializes easily and has all of the validation attributes you want.

Answer 4

I ran into this problem with MVC V1 and xVal. I ended up using "buddy classes" as detailed here Schotime (google cache as he's having website problems).

It works great for me, but I'm not familiar with MVC v2's method of doing this to know if its routines will "pick up" the metadata in your buddy classes.

It's hard to argue with anybody who starts with "everybody has a different opinion", but I'd be loathe to modify the generated files for LINQ. I see the point about a scaffold, but when I'm in development I'm making so many changes to my db (and relationships) that I frequently drop a class and recreate by dragging the table back over. Sometimes I remove all classes and drag the entire db over. On the other hand, I guess this is evidence of poor planning on my part.