ADO.NET EF v LINQ to SQL (take 2)

So after my first article covering the ADO.NET Entity Framework vs LINQ to SQL fiasco going on lately I got a some feedback from many sources who shared my pain so I thought I’d extend a second part.  To those that responded with the obligatory “ADO.NET EF is for pros, you just don’t know what you’re talking about,” – let me explain myself a little better.  I’m on Microsoft’s side here.  I’d really prefer them see make the right choice to get an even larger community for developing on their platform technologies.  This is not an anti-Microsoft campaign.

Recently Microsoft has posted another article about how “LINQ,” isn’t dead and that “LINQ to SQL,” is just going to be developed based on customer feedback.  I see two problems with this.  The first being that it seems like they’re getting a ton of feedback from their customers saying that LINQ to SQL is what they want.  Well if customers want it and they’re developing it, why is there an issue?  Seems like they’re just trying to soften the blow to the companies and individuals that have now wasted huge amounts of time.  I’m fully aware LINQ to SQL will never get the attention it needs, and why?  Microsoft recently announced Windows Azure which takes advantage of ADO.NET Data Services, which uses EF.  Meaning Microsoft is going to invest heavily in technologies they are personally using rather than the ones their customers are, it’s in their history.  As we’ve seen, history repeats itself.

I recently tried converting a existing ASP.NET MVC project of mine to use ADO.NET EF.  I figured since I used a pretty abstract DAL using the repository pattern this should be no problem.  However, using ADO.NET EF was a nightmare to say the least.  I couldn’t easily get tables using extension methods or generics.  I wasn’t able to use .Single() or .SingleOrDefault() extension methods without getting an exception and it made me actually make huge changes to my DAL.  After hours of frustrating coding sessions I finally had a working copy of my DAL hooked up with ADO.NET EF.  Suffice to say after using it for a few hours I quickly reverted to LINQ to SQL and never looked back.

Now is the time Microsoft.  As I said previously you’re forging along with a new Microsoft the likes of which have never been seen before.  Contributing to open-source projects, including un-forked open-source projects and even allowing people to download the source of the work you spend so much money on.  Many of us appreciate that and are glad to see you doing it.  I, as a customer will be sad to say I will be looking for alternate technologies if LINQ to SQL does not get the attention it needs.



  • EF potentially covers all databases while LINQ to SQL is only for SQL Server.

    MS has the choice to keep one. Keeping both would be bad for the architecture as a whole. (maintenance problems etc).

    LINQ to SQL will be deprecated and you'll be hosed in the future if you keep working on it.

  • I'm not a MS basher either... I think they've been doing a really amazing job, especially in the development arena for quite a while now (including LINQ to SQL) but it is a real shame they revert to this type of behaviour that we thought was in the past :(

    EF may well be a technically better product but LINQ to SQL is a real-world better product in our opinion. As already stated, people love it, people use it and companies haver made a huge investmet in it... which is about to be wiped out.

    Do the right thing Microsoft.


  • @vidalsasoon

    I agree for the most part. If EF were made the part of LINQ to SQL I would be happy but again that's the point is that Microsoft has huge branding issues when it comes to -- well, everything. I'd really like EF to be an extension of LINQ to SQL that provides access to enterprise-level DBs and DataServices etc...

  • @vidalsasoon

    That's like saying that MS should choose between MVC and WebForms because keeping both would be bad for the architecture as a whole.

  • I don't understand why you would tie yourself to another MS data access technology.

    Just pick NHibernate or LLBLGen and be done with it.

    The platform should serve you. You don't serve the platform.

  • @T. Ferguson

    Because usually they offer many more features than the frameworks you mentioned mainly because they get the jump on what's changing in the framework. These other data access technologies usually lag behind a bit with features and keeping up to date.

    Used NHibernate at my last job, I'll never use it again.

  • Wow! I could not even guess about it)) Not bad.

Comments have been disabled for this content.