There isn’t coupling between the LINQ to SQL generated and your own code at an entity level – the properties are just there and thanks to partial classes you don’t even have to ever look at the source.

I see ORM as commoditising, as part of the toolset and environment. As such I rely on higher-level tests to expose any flaws in the ORM just as I wouldn’t test parts of the .NET framework directly to make sure lists and math work.

I can understand the extra level of abstraction required when modelling objects against legacy systems or for very complex environments but in many of the recent projects I’ve worked on there has been a 1:1 relationship between the database and objects.

[)amien

The point of coding a PI domain and then implementing the mapping once you are happy is that your changes flow from the domain out to the DB, not the other way. You don’t need to remember to modify the the map for DB changes, because you don’t change that first. Instead you write tests to persist the entity, once you are happy with its domain representation.

Its the tests that preserve correctness – not the tooling.

The other extreme is a run-time layer which attempts to map using metadata. This really can introduce a black-box that may not scale, move with your technology or provide hidden gotchas at runtime you can’t get a handle on.

Code generation is a good compromise between these two and I have been using custom CodeSmith templates for some time.

Linq to SQL keeps the code generation light and restricted to a datacontext and entity classes. The data mapper/table classes use metadata on the entity classes.

The entity classes are pure property-only mappings of the fields as you would expect. The exception to this rule is the one-to-many relationship which requires a wrapper to resolve the relationship and it is this that requires the default constructor to be called.

The whole issue could be resolved if the designer/SQLMetal just made these properties construct inline as part of the definition.

[)amien

The trick for PI is not to use the designer generated code, but start with a clean class and then map manually. The code generation from LINQ to SQL produces a ‘fat’ solution to the problem, with optimizations that you may not want to take until you know you need them.

If you want clean code, follow the TDD approach and write it yourself. A lot of code generation is fast food – quick and cheap – but filled with nasty additives that damage your long term health.