Recreate Linq to Sql code when table changes where customised

Question

I have a Linq to Sql Model generated by VS ORD, but I want to make a changes to it to work around a couple of issues. I can change the designer.cs generated code , but if I ever need to recreate a table within the model, then I delete it and drag it back to the ORD. This however loses all of my customisations. Is there another way?

I have seen reference to sqlMetal.exe, but not sure how I would use this to get around the issue.

For information my customisations are as follows:

1. I am using Guid's and want the db to default these values, therefore I want to change the default linqtosl behaviour to add the attribute [Column(IsDbGenerated= true)] to the ID properties.
2. the Default Model Binding for MVC is not working for a collection (EntitySet<T>). To work around this I need to change the setter for these collections slightly.

Neither of these changes are particularly big, but my database could change considerably over time, and I need to remember to do each customisation each time.

Answer 1

This is what "partial" classes are all about. L2SQL creates your entity classes as "partial", so you never have to edit the designer-generated code, even if you recreate yur entity model.

Answer 2

I've had this same question and was hoping to see an answer appear here that solves both of the points you mention. (I found another workaround to your item #2, although your idea of using OnCreated() in a partial seems nicer than what I'm currently doing.)

I did run across an article recently (which I'll link to below) which might be an applicable solution to achieve these goals. This article describes how the author (1) uses SQLMetal to generate a dbml file, (2) runs a custom process which parses and modifies this dbml file to suit his needs, then (3) uses SQLMetal again, this time feeding in the modified dbml file, in order to generate code. It may be a lot of work for small projects/schemas, but I could see how this might be a handy workaround on large projects.

Here's the link: http://www.onedotnetway.com/enum-support-with-linq-to-sql-and-sqlmetal/

Best of luck! -Mike

Answer 3

I've trodden down this path before and the only reliable way is to move away from the sqlmetal.exe / dbml path and get involved with a custom class generator like LINQ to SQL templates for T4.

http://l2st4.codeplex.com/

The reason you need to use something like this is because you need to have your class generator pull your custom change information from different source. I ended up putting custom into the generated XML that the Dbml traditionally uses. Then I modified the t4 templates to spit out the custom classes I needed.

A warning: This ended up being an utter nightmare to implement and was discarded in favor of a notepad file of custom changes. We would just have to burn through them as needed. IMO this is one of the weakest points of Linq2SQL and a big reason I've explored other ORMs for future projects.