Danny Simmons compares the Entity Framework to similar technologies
It seems that everyone else is chiming in on Danny Simmons' recent comparisons of the Entity Framework with other similar technologies. There are several items I wanted to address from his observations.
Regarding the EF vs. LINQ to SQL, he makes two basic points: 1) That there isn't a provider model for other data sources and 2) That LINQ to SQL requires a 1-1 table to object mapping. On the second item, there is no denying the limitation. While you can work around the issue with LINQ to SQL's support for views, stored procs, and functions, this is the key differentiator between LINQ to SQL and the Entity Framework. Danny's statements regarding inheritance limitations and entity splitting both stem back to the TPH (table per hierarchy) limitation of LINQ to SQL.
Regarding the issue with the provider model, the original intent was to have a full provider model which vendors would be able to consume. When the ADO vNext initiatives came out, it was fairly clear that the provider model would be supported in the Entity Framework. As a result, the provider model for LINQ to SQL was essentially shelved. That was the genesis of Matt Warren's series on building an IQueryable provider which basically outlines how one would go about building a provider for LINQ. Since Matt has basically handed the LINQ to SQL code base over to Danny's team, we'll see where this progresses.
In Danny's discussions of other technologies, he seemingly makes two contradictory statements. In the beginning he states,
"... the truth is that different problems merit different solutions."
He then goes on to the statement:
"This makes it easier to create a conceptual model which is how you want to think about your data and then reuse that conceptual model for a number of other services besides just building objects. Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc."
By this, he is indicating that the EF should be the defacto mechanism for building the entity structures around which the various components of your system will be built. Thus one tool to answer the various solutions. Is the EF really the best way to expose relational data from a reporting or analysis perspective, time and performance analyses will tell. He does go on in the comments to his post indicating that he is not necessarily advocating re-using the same entities for all of these various application components, but rather to use a similar tooling to create the potentially separate entities that each subsystem will consume. While it makes the programmatic portion easier, the jury is still out on the other areas.
I'm still getting up to speed on the EF, but do have concerns regarding the POCO (Plain Old Class Objects) story and some of the other requirements that the EF puts on your entity and database models.