Ever since the release of the Entity Framework and the Linq to SQL team’s move to the ADO.NET team we have been hearing about Linq to SQL being dead. The ADO.NET team (which owns the EF as well) released the roadmap where they said:
“We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios. We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.”
This caused an uproar as you might imagine. So a few days later Tim Mallalieu, PM of the Linq to SQL and Linq to EF teams clarified by saying this:
“We will continue make some investments in LINQ to SQL based on customer feedback. This post was about making our intentions for future innovation clear and to call out the fact that as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios….We also want to get your feedback on the key experiences in LINQ to SQL that we need to add in to LINQ to Entities in order to enable the same simple scenarios that brought you to use LINQ to SQL in the first place.”
Sounds pretty dead to me. If you don’t believe me, just talk to any Fox Pro developer, VB 6 developer, or any Access developer who loves the Jet engine. They are still “supported” as well. As this has shaken out over the past month or so, there are two camps:
I told you so! and No way man, it is part of the framework, it will be supported for 10 years!
Well they are both wrong.
The I told you so crowd is claiming victory. While Linq to SQL may be dead, Linq to SQL has a lot of traction in the developer community. According to Data Direct Technologies’s recent .NET Data Access Trends Survey (November 24th, 2008), 8.5% of production .NET applications use Linq to SQL as their primary data access method. While this number is not huge, you can’t ignore these developers voting with their feet by using Linq to SQL in their applications.
The “It is in the Framework” crowd also has it wrong. Just because something is in the Framework does not mean it will have a bright future. Windows Forms is in the framework and WPF is the “preferred” UI for Windows apps. ADO.NET is in the framework and Linq to SQL and EF are suppose to replace that? Is anyone using System.Object anymore, or are we all using Generics?
So what should the Linq to SQL developer do? Throw it all away and learn EF? Use nHibernate?
No. The Linq to SQL developer should continue to use Linq to SQL for the time being. If the next version of the EF is compelling enough for a Linq to SQL developer to move to EF, their investment in Linq to SQL is transferrable to Linq to Entities. If Linq to SQL developers are to move in the future, Microsoft will have to provide a migration path, guidance, and tools/wizards. (The EF team has started this process with some blog posts, but the effort has to be larger and more coordinated.) When should the Linq to SQL Developers move to the EF? When this happens:
- The EF feature set is a superset of the Linq to SQL feature set
- Microsoft provides migration wizards and tools for Linq to SQL developers
If Microsoft is serious about the Entity Framework being the preferred data access solution in .NET 4.0, why will have to do a few things:
- Make EF 2.0 rock solid. Duh.
- Explain to us why the EF is needed. What is the problem that the EF is solving? Why is EF a better solution to this problem? This My big criticism of the EF team, the feedback I gave them at the EF Council meeting, is that they are under the assumption that “build it they will come” and have not provided the compelling story as to why one should use EF. Make that case to us!
- Engage with the Linq to SQL crowd. This group can continue to provide feedback to the EF team since Linq to SQL has many features that EF/Linq to Entities needs.
- Engage with the nHibernate crowd. Data Direct Technologies’s survey says that 18% of all .NET production applications use a framework like nHibernate, Open Access, or Spring.NET. (they also included ASP AJAX in this question, which is strange to me.) While you may not win all of these people over, you should find out what they like about their tools.
- Engage with the “stored procedure” crowd. The EF team on several occasions said that “Nobody is building an application using stored procedures and straight ADO anymore.” According to Data Direct Technologies’s survey, almost 65% of .NET developers are using straight Stored Procedures and ADO.NET and 14% are using the Enterprise Library, which is just a wrapper for SPs and ADO.NET. I am not attacking or defending this architectural decision, but the EF team has to realize that if this many of their customers are using this approach and there needs to be guidance, training, and migration tools, not to mention a compelling reason to move to EF.
How will this shake out? I can’t tell you since I have no idea.The EF team (and nHibernate crowd) talk like the train has arrived at the destination already while in reality it has not even left the station. We are still at the station buying tickets (to an unknown destination). Stay tuned.