Going, going, gone awry

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.