MS has announced that LINQ to Entities will not ship with Orcas. I think this is sensible as it seemed to be short of what was required from prime time. Better to get it right than to ship it.

MS has clarified their positioning of LINQ to Entities and LINQ to SQL in a new post. The post outlines the vision behind the Entity framework; and by implication behind LINQ to Entities which uses LINQ syntax as a query mechanism for LINQ to Entities. A key phase would be that the: "ADO.NET Entity Framework... [enables] applications to write to a conceptual data model with strong notions of type, inheritance, and relationships." Essentially the ADO.NET team have implemented an ADO.NET provider that consumes an abstraction of the underlying data source, be the DB or something else and allows developers to query against that store using an abstract form of SQL called ESQL. ADO.NET works as before against this new provider, but uses ESQL or you can use LINQ to Entities.

This is a noble vision of independence from the underlying physical storage; however, I think that we need to bear in mind the YAGNI principle. In a lot of cases the abstraction provided by a single mapping file or attributes, as in LINQ to SQL or other ORM tools like NHibernate or Wilson O/R Mapper, has proved to be more than enough to insulate us from the DB and the additional complexity of the new ADO.NET provider is not required. We have solutions that work without it, today.

For me the sweetspot for LINQ to Entities - legacy database systems or complex mapping requirements - means the tool is too complicated for most instances. The POJO movement was a reaction to the overcomplexity of J2EE. Hopefully we can learn from the Java community and not repeat their mistakes by forcing engagement with product that is too heavywieght for many tasks. Otherwise I forsee a 'plain old SQL' movement rising up against the complexities of the Entity Framework. The Entity Framework will suffer as a result from being pitched in the wrong space,.

The key to most ORM toolsets adoption is the productivity benefits they bring and the clean programming model - persistance ignorance - that they support. When I look at LINQ to Entities I see the former being dragged-down by additional abstractions and in the latter case entirely absent; by contrast, LINQ to SQL hits both of these spots.

LINQ to Entities is overcomplex for many needs and its use in many scenarios defies Occam's Razor - Entities should not be multiplied beyond necessity. For simple mapping scenarios, LINQ to Entities feels bloated and I don't want to use until I have to use it. The very design goals for LINQ to Entities preclude it ever being a simple solution.

It is interesting to note that MS states that the reasons to use LINQ to Entities over LINQ to SQL are as follows:

If you are writing an application that requires any of the following features, you should use the ADO.NET Entity Framework:

The ability to define more flexible mapping to existing relational schema, for example:

• Mapping a single class to multiple tables
• Mapping to different types of inheritance
• Directly Modeling Many to Many relationship
• Mapping to an arbitrary query against the store

The ability to query relational stores other than the Microsoft SQL Server family of products.
 The ability to share a model across Replication, Reporting Services, BI, Integration Services, etc.
 A full textual query language
The ability to query a conceptual model without materializing results as objects

Some of these look like very valid scenarios for LINQ to Entities; we do need support for complex legacy structures that do not map well on to simple ORM tools, and I would welcome the Entity Framework in that context - we have a legacy DB that falls firmly into that position; however bitter experience suggests to me that trying to build a shared model across Replication, Reporting Services, BI, Integration Services, etc is a nightmare and you should consider just having a seperate model for your transactional stores from your reporting stores etc and using SQL and BI tools to do your transformations. Don't do evil to begin with.

However the decision not to support querying to relational stores other than Microsoft SQL Server from LINQ to SQL seems to be deliberately crippling that product for no good reason. The provider model should be exposed and other implementations encouraged. Isn't that the value of LINQ? This feels like an internal turf war over who provides the standard data access layer to .NET developers. As a customer I am not interested in your internal disputes but in solving my customer's problems with your tools. LINQ To SQL should be capable for simple mapping scenarios across backend types and the provider model should be opened up for that. Do not force us to swallow the whole LINQ To Entities pill, just to get support for mutliple backends. This is not a reasonable decision.

Similarly I would hope that later releases of LINQ to SQL could be enhanced to support many-to-many associations and table per concrete classes inheritance strategies. Why force an upgrade to LINQ To Entities to obtain these feature sets which are common to many ORMs which do not have an additional abstraction layer? I do not see any technical reason for the Entity Framework being a requirement for these to work. NHibernate and Wilson for example, already provide these capabilities on the existing ADO.NET framework.

Experience with many MS developers suggest that if you give an 'upgrade path' to LINQ to Entities you will implicitly degrade LINQ to SQL as being a toy. It is not; unless you make it so.

Come on give us the LINQ to SQL we deserve and keep the Entity Framework for the complex scenarios that require that level of abstraction? Hell, the 'Plain Old LINQ to SQL' movement starts here. Feel free to join up!