LINQtoSQL Practical Best Practices

goinawry — Sun, 13 Jul 2008 03:03:52 GMT

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.

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.
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.
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.
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.

Using LinqToSQL LinqDataSource across multiple tables

goinawry — Fri, 20 Jun 2008 23:28:14 GMT

I’ve been recently using LinqToSQL with a current project and finally got down to business where I needed to work with fields from multiple tables. LinqToSQL is nice, but it does have it’s drawback that it maps objects directly to the schema. Fortunately, it maps their relationships too. Let’s avoid the discussion of LinqToSQL pros and cons for now and figure out handling multi-table fields.

Did I mention I’m using the LinqDataSource? Oops… that too. I’m not a fan of the built in sqldatasource and linqdatasource, but when you’re prototyping they’re a great way to get something up and running (save the business logic layer for when you actually HAVE logic). The catch is, they tend to do a bit more than what you want them to. This is the case I stumbled into.

Getting to fields from related tables requires that you understand the underlying LinqToSQL classes. Once you have those, it’s just a matter of typing in the <%# Eval("blah.blah”) %> statement.

An example of this has been done and written up nicely by Todd Anglin- Todd's blog

In my case I have a primary key, PackageTestSystemID, for a join table holding PKs to 2 other tables – PackageVersion and TestSystem. Displaying PKs is not user friendly, so I use the Eval statement to get the PackageName, Revision, and TestSystemSerial from the related tables. Shown below.

<telerik:GridBoundColumn DataField="PackageTestSystemID"

DataType="System.Int64"

HeaderText="ID" SortExpression="PackageTestSystemID"

UniqueName="PackageTestSystemID" AllowFiltering="false">

</telerik:GridBoundColumn>

<telerik:GridTemplateColumn HeaderText="Package" UniqueName="Package"

SortExpression="PackageVersion.PackageName" AllowFiltering="true">

<asp:Label id="PackageLabel" runat="server"

Text='<%# Eval("PackageVersion.PackageName") %>'>

</asp:Label>

</ItemTemplate>

</telerik:GridTemplateColumn>

<telerik:GridTemplateColumn HeaderText="Revision" UniqueName="Revision"

SortExpression="PackageVersion.Revision" AllowFiltering="false">

<asp:Label id="RevisionLabel" runat="server"

Text='<%# Eval("PackageVersion.Revision") %>'>

</asp:Label>

</ItemTemplate>

</telerik:GridTemplateColumn>

<telerik:GridTemplateColumn HeaderText="Tester" UniqueName="Tester"

SortExpression="TestSystem.TestSystemSerial" AllowFiltering="false">

<asp:Label id="TesterLabel" runat="server"

Text='<%# Eval("TestSystem.TestSystemSerial") %>'>

</asp:Label>

</ItemTemplate>

</telerik:GridTemplateColumn>

</Columns>

This is done in Telerik’s RadGrid control. For those who are working with the standard gridview, it’s a snap too. Scott Guthrie shows how- Scott’s blog

The catch is, I got all of this to work with the LinqDataSource, TestPackageLDS, shown below-

<asp:LinqDataSource ID="TestPackagesLDS" runat="server"

ContextTypeName="EM.Facility.DAL.FacilityEMDataContext"

TableName="PackageTestSystems"

EnableDelete="True" EnableInsert="True" EnableUpdate="True">

</asp:LinqDataSource>

Which produces the Grid-

However, I didn’t start that way. Since I was going to just display this information. I initially had my TestPackageLDS with insert, update, delete Not enabled. Without these enabled, I’m guessing the TestPackageLDS decided to not get them and you see the following grid and get to wonder… where’d it all go.

Enabling just one of the update, insert, delete options and voila, problem fixed. I have not attempted this with the Gridview, but I suspect the issue lies in the LinqDataSource and the results will be the same. The LinqDataSource (and SqlDataSource) are useful tools for prototyping and simple applications. You could say they let you cheat, and you know cheaters never prosper. In this case, they just had me work a little bit to pay my dues. Have fun, I hope this helps.

John.