LINQ to SQL Takes a Back Seat to EF

Well, it's official. One of my predictions ( has somewhat come true. Microsoft officially announced today on the ADO Team Blog ( that starting with .NET 4.0 (the next release), Entity Framework will be THE choice of relational LINQ technology, and LINQ to SQL is taking a back seat.

This all made sense to me, because LINQ to SQL's limitations were just lame. It looked and felt like a tie-over product, meant to hold the LINQ to DB line until something better came along. The problem was that the "something better" (EF) still needed a lot of development work and wasn't ready by the time VS2008 was out the door.

Of course, that leaves a lot of people who invested time in learning LINQ to SQL a little steamed (don't you wish you had listened to me? - j/k!!). But take heart - a lot of the concepts do in fact carry over from LINQ to SQL to EF. Even if the biggest thing you learned was just how to deal with LINQ in the first place, then you've already got a good leg up on EF.

But strangely enough, looking at the comments on the blog, it seems like people are really misinformed about EF (and writing angry comments that don't have much basis in fact). So here's the Rob version of FactCheck:

SPIN: Entity Framework is more limiting than LINQ to SQL
FACT: It's just opposite. LINQ to SQL only works with SQL Server, while EF works with just about any DB. Also, the resulting SQL is more capable, and in some cases, more optimized, in EF than in LINQ to SQL. That perf-and-feature gap will only continue to grow as EF matures even more and MS dumps more money into it.

SPIN: LINQ to SQL was better because it allows for domain-first design
FACT: Not true at all. Entity Framework is much better at allowing you to design in a domain-first manner. That is a primary goal of the technology. It allows you to decouple the conceptual "entities" from the physical store layout. With LINQ to SQL, all you get are datasets tied to a single physical entity. That 1-to-1 limitations stinks because a conceptual entity may be split and normalized across multiple tables in the physical store. Also, the entities you get back with EF are true observable objects rather than datasets with smoke and mirrors (as is the case in LINQ to SQL). All this allows you to better represent your domain in EF than in L2S.

SPIN: LINQ to SQL was better at persistance ignorance
FACT: If you've already read the two previous facts, this one should be obvious. EF allows access to any DB while LINQ to SQL allows only access to SQL Server. For persistance ignorance, that means EF 1, L2S 0. You can't be ignorant of the persistance mechanism if you are forced to use one and only one persistance mechanism. FAIL. And because you can create your conceptual entities separately from the physical layout of the store, EF 2, L2S 0. In other words, L2S ties you specifically to the underlying table/view/SP-return structure, and that is NOT persistance ignorance.

SPIN: OK, screw you and your facts, LINQ to SQL was just easier
FACT: That's partially true. The problem here is that EF is much (MUCH) more capable than L2S, and that adds more levers and knobs to tweak. The second problem is that if you've played with EF v1, then you'll note that the GUI IDE tooling for EF seems a bit lacking. That's because it is. However, once completed, EF's IDE support will rival (if not surpass in some areas) anything L2S has exposed so far. To be quite honest, a lot of it will work in a fairly similar manner - a designer to define entities, and a mapping UI. Some scenarios are very difficult to do in v1 because the IDE support is incomplete and you have to write extra code or muck with the uderlying XML definitions. As EF matures and goes on to future releases, that will go away.

posted @ Friday, October 31, 2008 11:33 AM