how do you generate class for LINQ to SQL?

Question

I am using linq to sql for my mvc 3 project. There are several ways to generate domain modal class files.

sqlmetal
Object Relational Designer
hand code

I always hand code those model class files. because files generated by sqlmetal or designer are messy. whats your opinion? whats the best way to do it.

EDIT:

I am using MVC 3, not 2. Maybe I am wrong, but this is how I validate. I gonna end up writing all those class files anyway, so whats the point to use tools to generate them???

public class User
{ 
    [Required]
    public string Password { get; set; } 
    [Required, Compare("Password")] 
    public string ComparePassword { get; set; } 
}

The point of using tools (L2S, T4, whatever) is that you're prone to make mistakes *whenever* you hand-code something. Plus, it saves you from the mind-numbing tedium of wiring all that up. I've got T4 templates that will generate the *EXACT* structure you're describing, but I never have to think about it - just regenerate whenever the object model changes. This lets me focus on the actual application logic. — GalacticCowboy, Jul 13 '11 at 14:08
I'll also add that repeating yourself (violating DRY principles) is at best a time waster and at worst error prone. As an example, you should only have to specify once how long your character strings are. If you do it in your table and again in your object you're doubling your effort and risking being out of sync. Avoiding that is a big advantage of doing code-gen, no matter how you do it or which data access tech you use. Entity Framework actually embraces this by providing T4 templates right from VS. If it supported cross DB queries and better query logging, we'd probably switch. — mattmc3, Jul 13 '11 at 14:56

score 4 · Accepted Answer · edited May 23 '17 at 12:06

We have hundreds of tables across multiple databases (one server). We do table first development, drag the tables onto different DBML designer files each in different folders representing different namespaces within each project. The designer files are marked not to compile, and we use a custom built T4 template that generates our code by reading from whatever DBML files are in the project. This lets us have full control of the code that's generated, so we can do things like implement an interface (IAuditable is one example where we have CreatedBy, CreatedDate, ModifiedBy, ModifiedDate). We can also put System.ComponentModel.DataAnnotations on our Linqed objects this way too without resorting to Buddy Classes. We have a second T4 template that's in charge of refreshing the DBML from the database, so we can ensure that tables have the 3 part prefix (db.schema.tbl) and so we don't have to delete and re-add to the designer. The XML just gets changed based on reading the db schema and updating the DBML. We also generate a repository/manager object for each POCO that have a few common query operations like GetByID(), and also handle commits and the audit logging. These managers get extended with all the custom queries you'd need to write against each table, and they own the DataContext. This design is sometimes known as the "Mommy-may-I?" approach, where the object Linqed to the table has to ask its manager to do everything for it.

I've found this to be a very versatile and slick way of doing L2S, and it's made our back-end development a breeze so that we can put our focus on the user experience. The only downside is that if we do associations across namespaces, you have to manually add those to the partial class yourself, because otherwise you'd have to add that foreign table to another DBML in order to draw the association. This is actually not such a bad thing as causes us to really think about the specificity of our namespaces and cut down extra ones. Using T4 this way is a great way to develop DRY (don't repeat yourself). The table definition is the only place you need to change the structure and it all propogates. Validation goes in one place, the POCO. Queries go in one place, the manager. If you want to do something similar, here's a good place to start.

I am using MVC 3. I still need to write every class for validation. so whats hte point to generate them using those tools. public class User { [Required] public string Password { get; set; } [Required, Compare("Password")] public string ComparePassword { get; set; } } — qinking126, Jul 13 '11 at 12:32
We are using MVC 3 as well. Our generated generated classes are still Linq-to-SQL partials just like MS makes them, only with some enhancements. For example, if the DB table's column doesn't allow NULLs, then the [Required] attribute is added for you as well as string length, etc. — mattmc3, Jul 13 '11 at 12:52
Also, there is a validation method provided for every class that you can implement for business logic validation. So the only code you write is the code you actually need to write - queries and business validation. The rest of the time we can focus where we need to - on the user experience. — mattmc3, Jul 13 '11 at 12:59

score 0 · Answer 2 · answered Jul 13 '11 at 00:39

Even tho the Designer generated classes are messy, what does it matter to you?

There's, I dare say, absolutely no need to ever open one of the design files.

If you need to extend any of the entities defined in your model, they are all partial classes so you can just create your own partial class of the same name and implement your stuff...

When I do use L2S, I just use the designer.

how do you generate class for LINQ to SQL?

2 Answers2