Bet on Entity Framework, not LINQ to SQL

So says Roger Jennings in his post Is the ADO.NET team abandoning LINQ to SQL? His main points in favour of ADO.NET Data Services (formerly Astoria) Entity Framework:

  • It is the focus of more energetic development
  • It already has richer features
  • It supports multiple database engines, not just SQL Server

As Andres Aguiar, software architect at Infragistics, notes in a comment, this has a lot to do with internal politics at Microsoft:

The Data Programmability Team never owned LinQ to SQL, it was owned by the C# team. That’s why we have two O/R mappers, both teams wanted to ship theirs. The C# team looks to be thinking about functional programming now. The Data Programmability will always be thinking about data. That’s why the EF [Entity Framework] is the safe choice.

Although LINQ to SQL is now (apparently) owned by the SQL Server team, it still doesn’t seem plausible or sensible that both will get equal attention. We also learn from Matt Warren that LINQ to SQL was deliberately tied to SQL Server only:

LINQ to SQL was actually designed to be host to more types of back-ends than just SQL server. It had a provider model targeted for RTM, but was disabled before the release. Don’t ask me why. Be satisfied to know that is was not a technical reason.

Note that this wasn’t necessarily a plot in favour of SQL Server world dominance; keeping the entire stack as a Microsoft stack no doubt makes support easier. That said, to me this is the big weakness of LINQ to SQL.

I was impressed by Astoria when I first saw it at the European Tech Ed in 2007. I am not surprised it is gaining ground.

2 thoughts on “Bet on Entity Framework, not LINQ to SQL”

  1. Hi, Tim,

    My point was that Entity Framework, not SQL Server Data Services, was a better bet than LINQ to SQL for a production object/relational mapping (O/RM) data layer.

    My post mentioned ADO.NET Data Services in passing as a client of Entity Framework (as is ASP.NET Dynamic Data.)



Comments are closed.