People are always asking “when will I be able to use LINQ against databaseA or databaseB?” and “when will I be able to use Entity Framework against databaseA or databaseB?”
In my mind this is the same question, though most who are asking don’t realize it. Why?
An Entity Framework provider gets all of the benefits of the Entity Framework and also gets LINQ for free by way of LINQ to Entities.
If a database vendor wants developers to be able to perform LINQ queries against their database, it’s not a stretch to think that they might also want developers to be able to use their database within the Entity Framework.
Why write two providers (a LINQ provider AND an EF provider) when they can write just an EF provider and with it, get LINQ capabilities as well?
An added benefit is that with Entity SQL, it is possible to add provider specific functions. So when a developer reaches a wall trying to write a LINQ query, the can just step back and use Entity SQL for those cases.
I’m definitely using LINQ to SQL where it makes sense for me. In fact, I’m waiting for a sysadmin to throw .NET 3.5 on my client’s web server so I can deploy my first production solution that uses LINQ to SQL! 🙂
But for any other db’s, I’m not waiting to see who is writing LINQ providers for their databases, but who is writing EF providers (here’s a current list, by the way).
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
As it has turned out there are very good reasons to have both approaches available. LINQ to SQL is better for simple RAD projects where the entity model matches the data model and EF is better for larger projects where models are more complex or could change over time.So as it appears now, any DB that want’s to compete with SQL Server will eventually need to hve more than just an EF provider.
[just playing devil’s advocate here…]But you can conceivably use EF without taking advantage of it’s bigger benefits. Granted there are some RAD benefits of LINQ to SQL that you would miss out on, such as it’s dynamic deferred loading vs. having to explicitly force the deferred loading in EF.Julie
bullet proofed O/R Mappers supporting different database vendors and LINQ will make the race, no? what I hear from engineers is that L2SQL to simple for real world productivity coding and mapping requirements and EF too complex. both show the way but won’t join the journey.