LINQ to SQL, EF, and the Thunderdome Solution

There is a lot of comment around recent pronouncements from the ADO.NET team that their future strategy for ORM will be Entity Framework and not LINQ to SQL. Having posted a fair amount on LINQ To SQL, trying to highlight its strengths as an ORM solution, I wanted to comment  on how I see this development. This will not be a knee jerk ‘They killed Kenny…’ reaction, so I hope it will add to discussion rather than be just one more voice of dissent.

Do you hear that, Mr. Anderson? That is the sound of inevitability.

The rationalization of MS’s ORM strategy has been inevitable since L2S and EF appeared on the scene. Questions were asked about it before VS2008 even shipped. So MS was always likelty to try and rationalize the two approaches into one. Having two ORMs would end up being confusing to many customers, unless they could be clearly distinguished.Having worked for ISVs that had competing products customers only
end up confused by you competing with yourself, and that leads
customers to look elsewhere. So ratiuonalization was always the likely end of this story.

In one sense this is a positive step. Product confusion is removed from customers as to which platform is MSs strategic offering. Resources are focused on providing one good solution over two mediocre ones. So I think it is important to see how this news could have a positive outcome.

LINQ TO SQL has great design but lacks some functional richness. Entity Framework has a poor design but is functionally richer. The two products have complimentary strengths and weaknesses. Fixing them both would only further confuse the picture of which one to choose.

So I think that many of us have been expecting some sort of announcement that clarified where these two products were going.

Two men enter, one man leaves

My problem with the proposed direction though is that the Thunderdome approach seems to have been taken. Two products enter, one product leaves. With both products coming under the ADO.NET team, the home product, Entity Framework was always the favorite, playing in front of its home crowd. Some of us tried to yell our support for LINQ To SQL from the sidelines. But ultimately a Thunderdome contest was only going to have one outcome:

Not Invented Here.

Our lack of confidence issue in EF will not be solved by simply removing its competitors. What we need to see is increased understanding of the criticism. But the announcements still fail to point out the areas where LINQ To SQL is a better solution than EF. L2S has many features that EF badly needs such as domain-first support, POCO, performance of generated SQL, lazy loading, etc. Without public acknowledgement of those strengths doubt must remain as to whether or not the ADO.NET understand why LINQ To SQL has such positive support.

Thunderdome was the wrong approach here.

LINQ to Relations – a Reimagining

A better outcome would have seen MS announce a successor to both LINQ To SQL and Entity Framework. Take the feedback from both productsand build something new. Let’s call it ‘LINQ to Relations’ or ‘LINQ to RDBMS’. For sure re-use where you can to save cost if you need to, but re-imagine. I do not imagine that the API changes would be any more significant than those that L2S and EF developers will face in the next iteration of your ORM anyway.

To do it you would need to take a hard and dispassionate look at what works with L2S and EF and build a new product that has the successful features of both, and none of the weaknesses. Bring members of the L2S team on board is positions of authority so that the team that produced the better design can get their voices heard. If they are willing. Get external review of what was right and wrong with both products. Trawl a wider range of opinions. We do not know who you are listening too, but on the evidence of EF, it is not a broad enough audience.

Most of all take Faulkner’s advice and be prepared to kill your darlings. Sometimes the features that you have most invested in, are not ones that should make the final cut of the re-imagining.

Then release early, and release often.

Some might ask if this is not what MS are really saying? Not from the annoucements I have read. The annoucements talk to an investing in EF not a re-imagining of the LINQ to RDBMS options. If it is re-imagining be honest about it, rather than trying to bounce customers into EF through Fear, Uncertainty and Doubt over LINQ To SQL’s future.






About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Hdnlvezk


  • Ian Cooper


    In terms of feature set I agree. LINQ To SQL seems like the better starting point. NIH I suspect.

    To be fair to the folks involved without seeing the codebases there is no way to know which is more amenable to change.

    However I feel that re-imagining might be a better solution than starting with one or the other codebase.

  • David Nelson

    It is far, far easier to add new functionality than to fix a broken design, which makes the decision to stick with EF instead of L2S that much more obviously a political move rather than a technical one. Its fine that they are trying to unify the two technologies; there should never have been two technologies in the first place. But if you have to pick one to use as your baseline going forward, doesn’t it just make sense to pick the one with a more fundamentally sound design, which also happens to be the one that enjoys much greater support in the community?

  • Ian Cooper

    @Borek Yeah I need to check out the PDC demos.

  • Ian Cooper

    @Chris It’s not what they have said. Their statement was pretty clear that future investment will be against EF, with L2S investment being at a support level.

  • Ian Cooper


    My point was more that the design approach taken by the LINQ To SQL hits the spot for the way we work. Our approach is:

    Write Acceptance Test
    Write unit test
    Create domain objects in reponse to unit tests
    Mark up domain objects for persistence
    Generate Db schema from domain model
    Implement acceptance test

    So we need support for things like POCO, marking up a domain model, generating a schema from a domain model.

    We also want true lazy loading (both collection and entity level), use defined type mapping (inc. enums and the like) etc.

    LINQ To SQL seemed to be closer on some of these, so my request for the architects of that project was that they had shown more sign of ‘getting it’.

    If the EF team want to send someone to the UK to see how we use products like NHibernate in anger, drop me a line

  • Chris Pietschmann

    MS is doing what they alway do with things. They listen to the users. If everyone keeps using LINQ to SQL, and complaining about issues and asking for features, then they WILL add to it.

    This is like say “MS killed DataSet and DataReaders”. Simply not true, it’s still there, but they’re adding newer (hopefully “better”) things. You can still use it, it’s still in the framework.

    And, they aren’t really “killing” it; it’s not like they’re taking it out of the framework or anything.

  • Ed Blackburn

    I think if ever there was a real world example as to why one is well advised to use persistence ignorance, this is it. Diligent use of IRepository can assist in reacting to change. Be it infrastructure or technology changing under your feet, irrespective of the vendor.

  • Damien Guard

    The majority of people on the LINQ to SQL team had no background or experience with EF until we compared the two stacks.


  • Ray

    Yeah, what Borek said. The demos in that PDC video he linked by themself were compelling enough that I’ll give EF another look when V2’s out. Looks like you can go 100% POCO, POCO + EDM, and pure EDM/codegen (the out of the box stuff you can get now). Poco + an EDM wrapped around it so you can get all the benefits of POCO as well as the other stuff being built around EDM (astoria) will be very interesting.(Oh, and deferred loading support.)

  • Borek

    Domain-first support, POCO and lazy loading will be part of EF2 according to this (great) PDC talk:

    Hopefully, EF2 will be a lot like ‘LINQ to RDBMS’ as you described.