And the winner is… LINQ to Entities and the ADO.NET Entity Framework


In 2001 we first demonstrated Object Relational Mapping (ORM) technology for .NET – ObjectSpaces. However it has taken 6+ years to get to the point where we have released an ORM. Actually we released two.

  • The release of Visual Studio 2008 in November 2007 gave us our first shipping ORM – LINQ to SQL.
  • The release of Visual Studio 2008 SP1 in August 2008 gave us our second shipping ORM – LINQ to Entities or more specifically, the ADO.NET Entity Framework.

Which reminds me of waiting for a bus. You wait and wait and wait and then finally two come at once! Anyway – I digress.

Choice can be a great thing but it was pretty obvious that having two ORM technologies from one supplier was causing a lot of confusion amongst Windows developers keen to benefit from using an ORM on their projects. I have previously discussed how to choose between these two technologies but things have got much clearer over the last few days.

Last week Tim (Program Manager on the team) posted an update on the roadmap. My summary in one line would be:

  • The Entity Framework (v2) will be the recommended way of using an ORM in Visual Studio 2010 and .NET 4.0. LINQ to SQL will not.

There are clearly some implications that come out of this. I will have a stab at them in Q&A form. This is not an official Q&A – but hopefully is a helpful Q&A.

  • Is this good news? I think so. In this case choice was not helping us get the job done.
  • Will Entity Framework v2 include all the great stuff from LINQ to SQL v1 which was missing from EF v1? I don’t know about “all” but the clear intention is to make EF v2 exhibit the best qualities of LINQ to SQL whilst also maintaining the power and flexibility of EF v1 (support any RDBMS, complex mappings etc)
  • I have a huge investment in LINQ to SQL, should I be worried? Nope. If LINQ to SQL matches what you are trying to achieve then great. We have not stopped development on LINQ to SQL, rather we have made a clear statement that most of our investment in .NET 4.0 will be in the Entity Framework and not in LINQ to SQL.
  • I am about to start using one of these ORMs. Which should I now use? I think my previous post still broadly holds – but IMHO, if you have not yet started using LINQ to SQL then I would advise you went with EF v1.
  • Where can I find out more about EF v2? There was a session on EF v2 during PDC and there is also a blog discussing v2 features.
  • How can I migrate my LINQ to SQL code to LINQ to Entities? The team have started to blog out details of the differences. Expect more in the future.
  • Should I migrate my LINQ to SQL code to LINQ to Entities? Probably not 🙂 If you are happily using LINQ to SQL then the announcement last week should not worry you.
  • Can I use both LINQ to SQL and LINQ to Entities in the same application? Yep. You could have 100 screens implemented using LINQ to SQL and write the 101st screen using LINQ to Entities.
  • Eric – are you spending any more time on LINQ to SQL? Nope. I decided a few months back that a technology only focused on SQL Server was not where I wanted to invest time as I have traditionally worked with companies targeting many RDBMS.
Comments (4)

  1. Hi Eric,

    Here’s another question to add to the list:

    Will Linq to Entities performance improve to anything like Linq to Sql?

    Acording to http://oakleafblog.blogspot.com/2008/07/comparison-of-entity-framework-and-linq.html  Entity Framework takes 24 times longer to execute the first update/query combination and 5 times longer for subsequent (compiled and cached) operations with no sample data loaded in the underlying database

    – would be good to know if that still holds true with current releases too.

  2. James Hancock says:

    Linq to SQL had full provider functionality in the backend that was disabled.

    It works better, is easier to use, can have inherited objects, and is BY FAR, faster. Oh ya, and you dont’ have those mess of xml files that is incomprehensible.

    And now we have the crud of Linq to Entities that doesnt’ give you the flexibility, has a horrible designer (just try renaming an object, or trying to manually setup a relationship with that thing!), takes forever the first time you load it or save something on any reasonable sized table, and has horribly complex xml files that prevents you from being able to maintain it yourself. (for no good reason either)

    This day was obviously coming, but man, the C# team did a MUCH better job than the Database guys.  I’m glad I guessed right and went Entities even though it’s crapware, but it’s too bad to see the superior technology that just needed a few tweaks and it’s provider model de-crippled to make it fantastic DOA.

  3. weijun says:

    "but IMHO, if you have not yet started using LINQ to SQL then I would advise you went with EF v1. "

    Not sure a written mistake or not. v1 or v2?