LinqToSql Best Practices

Question

I just started creating my data-access layer using LinqToSql. Everybody is talking about the cool syntax and I really like Linq in general.

But when I saw how your classes get generated if you drag some tables on the LinqContext I was amazed: So much code which nobody would need?!

So I looked how other people used LinqToSql, for example Rob Connery at his StoreFront Demo.

As I don't like the way that all this code is generated I created my domain layer by hand and used the generated classes as reference. With that solution I'm fine, as I can use the features provided by Linq (dereferred execution, lazy loading, ...) and my domain layer is quite easy to understand.

How are you using LinqToSql?

Answer 1

The created classes are not as heavy as it seems. Of course it takes quite a few lines of code, but all in all it is as lightweight as it can be for the features it's providing.

I used to create my own tables, too, but now instead I just use the LINQtoSQL DataContext. Why? Creating is simpler, the features are better, interoperability works, it is probably even faster than my own stuff (not in every aspect. Usually my own stuff was extremely fast in one thing, but the generic stuff was faster in everything else).
But the most important part: it is easier to bring new developers into the LINQ stuff than into my own. There are tutorials, example codes, documentation, everything, which I'd have to create for my code by myself. Same with using my stuff with other technology, like WCF or data binding. There are a lot of pitfalls to be taken care of.

I learned not to develop myself into a corner the hard way, it looks fast and easy at the start, is a lot more fun than learning how to use the libs, but is a real pain in the a after a few months down the road, usually even for myself.

After some time the novelty of creating my own data containers wears off, and I noticed the pain connected to adding a feature. A feature I would have had for free, if I had used the provided classes.
Next thing I had to explain my code to some other programmer. Had I used the provided classes, I could have pointed him to some web site to learn about the stuff. But for my classes, I had to train him himself, which took a long time and made it hard to get new people on a project.

Answer 2

Use compiled queries. Linq to SQL is dog slow otherwise. Really.

Answer 3

We use our hand crafted domain model, along with the generated classes, plus a simple utility which utilizes reflection to convert between them when needed. We've contemplated writing a converter generator if we reach a point where reflection creates a performance bottleneck.

Answer 4

LinqToSql generates a set of partial classes for your tables. You can add interface definitions to the 'other half' of these partial classes that implement your domain model.

Then, if you use the repository pattern to wrap access to the Linq queries, so that they return interface implementations of your objects (the underlying Linq objects), LinqToSql becomes quite flexible.

Answer 5

You can hand-write your own classes and either use the LINQ to SQL attributes to declare the mappings or an external XML file.

If you would like to stick with the existing designer and just modify the code generation process pick up my templates that let you tailor the generated code.