Geeks With Blogs
Going, going, gone awry Technical ramblings from John Summers

I don’t profess to be an expert. But I have been using this technology in my current project. The typical, understaffed, hurry up and learn, show me something, release it (and yes it must be validated, but doing so is your problem). Here’s what I’ve picked up while  coding shotgun style.


  1. Table names and Field names should always be different. When table names and field names are the same, LINQtoSQL renames the field name with a name1. Then when you have a table with a field name that’s a foreign key to another table and the foreign key matches the table name, which has a matching field. Don’t go there, even if LINQtoSQL gets it correct, you won’t.
  2. Keep the database names the same between the development, test, and production databases. The default connection string embeds the database name in it. Typically, I think it’s good practice to pass the connection string (that’s defined in the .config file) when creating the datacontext. The problem lies when you mix linqdatasources with business classes, the linqdatasource creates the datacontext with no parameters and lies on the internally generated connectionstring name. This is dependent on the database names and  you have a problem. Business methods pointing one way, linqdatasources pointing another way. The simple solution, just use business methods or just use linqdatasources. However, I still find that linqdatasource is great for the quick and dirty read. It gives you all the bells and whistles, but when it comes to updates, creation, deletion, I like to have my say in exactly what happens.
  3. When in doubt recreate the whole dbml, adding and deleting tables individually may effect relationships. This may be a product of my own confusion, but considering how nicely VS2008 creates the classes for you, use it. One or all, it’s drag and drop, do them all and be done with it.
  4. Extend classes in external files named after the original class.  Put extended class files in a separate folder. The partial classes are great. This just helps to keep things sorted. I’m waiting to read about somebody extending the LINQtoSQL classes to contain all their business rules. I think it’s possible for given scenarios. Could be interesting.
Posted on Saturday, July 12, 2008 10:03 PM LinqToSQL | Back to top

Comments on this post: LINQtoSQL Practical Best Practices

# re: LINQtoSQL Practical Best Practices
Requesting Gravatar...
My thought on creating the data context is to always use an SqlConnection object.

Using an existing SqlConnection has a huge speed advantage when make a new instance and gives flexibility for the database name and connection string.

Having multiple instances of the data context is important for managing tracking of changes so that you can submit or cancel the changes within a controlled scope.
Left by Doug Ferguson on Jul 14, 2008 12:47 PM

# re: LINQtoSQL Practical Best Practices
Requesting Gravatar...
Never thought about a SqlConnection, I'll have to look into that, thanks! I don't think there will ever be a book on LinqToSQL best practices, but I have definitely come across things that I've found are best to avoid. As with the nickname, "goinawry", I swear, if there's a pit to fall in, I do so. I'm hoping to see more "best practices" on the subject because when I initially searched for them, I got nothin'. Best practices, or a list of pitfalls and explanations why have always bee a big help to me.
Left by goinawry (john summers) on Jul 14, 2008 8:36 PM

# re: LINQtoSQL Practical Best Practices
Requesting Gravatar...
You are welcome.

Some practices like using the same connection are the same as in plain ADO.NET.

I am still trying to figure out transactions and concurrency.
Left by Doug Ferguson on Jul 16, 2008 4:58 AM

Comments have been closed on this topic.
Copyright © goinawry | Powered by: