Bring LINQ to SQL down

There is a discussion on the net about LINQ to SQL and if it should be removed in the future. My collogue and friend Patrik Löwendahl wrote a post about what he think, you can read about it here. I don't care if LINQ to SQL will be removed, honestly I want it to be removed. As Patrik wrote in his blog post, it's not the ADO.Net Team that created the LINQ to SQL. I think the team that focus on data access etc should be the team that build data access framework and the ADO.Net Team are doing a great job. After watching a session in the PDC about EF in the future, I must say that I will not use nHibernate or other OR-mapper as I have mention before in some old posts, I will now use EF. If we compare LINQ to SQL today with the current version of EF, LINQ to SQL is best suited for RAD, but in the future even EF will be suited for RAD. What I don't like with LINQ to SQL, is that developers are using the database first approached, they generate a model out from a database schema. A database is not object oriented.

I don't think there is a reason to have two tools which is "almost" identical, just make one available.

10 Comments

  • I disagree with your last statement.

    That choice should be available. Removing frameworks because you disagree with the approach is quite extreme isn't it???

    "in the future..." - what is this future - when?

    There is nothing wrong with nhibernate.

    I don't know many shops that have dba's agree to let a dev just generate code first before the model. It should be a joint exercise. Usually it results in poorly designed db models. Or is ms going to create proper & well-tuned databases from my EF designer pages???

  • "I must say that I will not use nHibernate or other OR-mapper as I have mention before in some old posts, I will now use EF."

    Biased thought, i can say. NH is not staying as is, it is developing!

  • I totally agree. I have been using EF more or less successfully for well over a year. What the entity framework has been lacking they are actually adding as we speak. It is also very easy to extend those ef classes. It took some real thinking before I tossed Linq 2 SQL and NHibernate out the window. I believe EF is the right tool for me, and displaying it to colleagues they have all been impressed with the ease of use.

    This is a never ending debate in which O/R Mapper to use. I am just glad they finally drop linq2sql. It doesnt make sence anyway.

  • I can´t see a future for Linq to SQL, when we have Linq to Entities. Sure, I have had some really annoying problems with EF, but I´m sure it will will grow and evolve fast.

  • What made Linq2SQL so much superior (in design) to EF v1 was perhaps because it did not come from the data centric ADO.NET Team :)

    I can understand why MS wants to focus on one ORM framework, but it leaves a lot of linq2SQL users in the dark. It looks like they are fixing most of the show stoppers in EF v2, but I doubt that it will ever surpass NHibernate feature wise.

    But maybe great tooling will make it an interesting choose for v3 :)

  • @Steve:
    If the community had come up with two competing and different frameworks then that's fine. MS, however, should have a single preferred and supported framework. When MS competes with MS NO ONE wins.

  • I can understand their point of view of going forward with only one framework. Still though - why the hell did they release two in the first place? I know several projects that have chosen L2S as the basis for their datalayers. It has been around for just the amount of time for people to have adopted it, and now they are left in the dark?

    That's really poor customer management.


  • @Martin:
    They haven't left it in the dark.. It will still be available by the misstake they have done ;)

  • Mistake? The mistake was creating the entity framework instead of building upon what LinqToSql is. Have you even used EF? I'm surprised anyone can use it as fat and slow as it is.

  • Everybody. Uninstall your LinqToSQL item templates in protest (+ to support EF) :-)

Comments have been disabled for this content.