More on Linq to SQL

I decided to dive in and explore the Linq to Sql. Very cool I must say.
Linq to Sql is a ORM. It uses Linq as it’s Query ‘engine’. All queries can be performed using Linq.

A simple example of this in action is:

DataContext db = new DataContext();

var companies = from c in db.Companies
where c.Name.StartsWith(“A”)
select c;

In this C# code snippet, the DataContext is comparable to the NHibernate ISession. It handles all communication with the domain objects. Not to get into a big debate, but the idea here is that the Company domain object is persistent ignorant. It doesn’t know anything about the database, saving, editing, etc… It is an object. The DataContext know about such things however – it tracks the state of the object, etc and can track if the object is new or need to be updated, etc… This is what makes ORM very nice to work with. Developers work with objects. There is no SQL to know, etc.. no connection, command, adapter classes to wire up nor datareaders, datasets, etc… We are working with core Domain objects (look up Domain Driven Design on google if you are interested in more on this subject).

This query above just touches the icetip on the capabilities. I won’t attempt to cover all that in this simple post.

So, how does the DataContext know about Customer above? Let’s step back a moment and see how this is done by NHibernate and Castle’s ActiveRecord.

NHibernate separates the ‘database know-how’ from the POCO (plain object) – being Customer by using xml files to define the relationship. In the xml file it will give information regarding the table in the database, the fields and columns, how they relate to the properties of the object, etc… Or in the case of ActiveRecord , attributes are used over the class and members.


public class Customer: ActiveRecordBase

The attribute tells ActiveRecord how to relate this object to the database.

In my opinion, the xml is better in that it is more persistent ignorant than the attributes. However, both do the trick.

So, why all this explanation? You do have the option in Linq to Sql to use xml or attributes. By default, if you use the drag and drop interface or the command line SQLMetal tool to create the objects, it will use attributes.

So, what does this look like?

public class Customer
public string CustomerID;

private EntitySet _Orders;
[Association(Storage=”_Orders”, OtherKey=”CustomerID”)]
public EntitySet Orders {
get { return this._Orders; }
set { this._Orders.Assign(value); }
} As you can see from above, the attributes express to the DataContext object how the object relates to the database.I have heard some grumbling from the open source .net community over Linq to SQL, but honestly I have mixed emotions on it:1. I’ve become a big fan of ORM2. I’ve used NHibernate and ActiveRecord

For #1, I think having Microsoft finally, yes finally, get into the ORM market is good for all of us.

For #2, I don’t see those implementations going away. I see it rather as having more choices.

To learn the details of Linq to Sql, check out this MSDN reference here

To see a very cool movie that show some of Linq to Sql along with Silverlight and other cool ajax stuff – check out the ‘Mix07VideoPlayer’ application movie

The blog post for the movie information is here. If nothing here is interesting, see this movie, it is very very cool 🙂
Also, I highly recommend reading Scott Guthrie’s blog – he has several parts up regarding Linq to Sql. His latest is an ‘addon’ showing how you can see the SQL being generated by Linq which is very cool

Below are some blog posts he has made detailing some of how Linq to Sql works:

He’ll be adding more soon as well.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s