Freekshow

I have done a number of technical sessions on Linq, Linq to SQL and the ADO.Net entity framework recently. I will try to put together a number of posts here for those who want to get started on these technologies. One of the questions I get asked regularly concerns the difference between the different frameworks. I will try to highlight some of these in this post.

Since we had the lauch of Visual Studio 2008 last week, Linq to SQL is now widely available. Linq to SQL is a light-weight OR-Mapper. Is this the best framework for persisting your data? No, by no means. If you are currently using a feature-rich OR-Mapper like NHibernate or LLBLGen, you wouldn’t want to switch to Linq to SQL. However, if you’re new to the practice of OR mapping, Linq to SQl can be a good choice to get you started. 
Included in the ASP.Net 3.5 extension pack that’s going to ship sometime this year is the ADO.Net Entity Framework. This has all of the capabilities of Linq to SQL, and much more. To give you an idea, I’ve outlined the differences between these frameworks below:

This lists the main differences, but there is much more to tell. For now, let’s focus on the different ways these frameworks model the data classes.  You can generate a model in Visual Studio from an existing database by dragging tables from server explorer onto the designer canvas. Using Linq to SQL on one of my demo databases, the following data classes are generated:

Notice that we have a many-to-many relationship in the database: A person can be linked to one or more companies,  and a company can have a link with one or more persons.

Now if we import the same database using the Entity Framework we get a slightly different result:

First thing you will notice: the CompanyPerson table has no corresponding data class. This is what we want! This table is just a construct that is used in relational database modelling to enable the Many-to-Many relationship, but it is not an entity in our OO model, and should therefore be abstracted away by the framework of our choice. In the EF, you can see how the mapping is done through the Mapping Details:

We have a navigational property Companies for Person, and likewise a Persons property on Companies. Using Linq to SQL we would have to use the CompanyPersons data class (yuk) or we would need to write custom navigational properties to get the same result. This is just the sort of stuff we want a framework to do for us! It would seem that the ado team that is producing the EF has put considerable more effort into the translation of relational to OO concepts. Looking at the two different models, you might have notice another key difference(pardon the pun): the noticable absence of foreign keys in the dataclasses of the EF. We have a navigational property Country on the Person class, and from Country we can navigate to persons. Why would we want an attribute CountryID in our Person data class?

Next time I will dig a bit deeper into Linq to SQL.