I've prepared dozens of articles and presentations on the Entity Framework over the past year and a half and the questions always start with "Why would I want to use this instead of XYZ?" LINQ to SQL, a variety of ORM tools, straight up ADO.NET, custom data layers, CSLA.NET and this list goes on and on. This is a great questions and I was glad to see Danny Simmons of Microsoft addresses this today on his blog. Danny mentions the differences between the Entity Framework and a few of these alternatives and specifically points out situations where they don't follow the same music.
The differences between the choices are outlined well in Danny's post. However the key point I want to stress is what Danny calls out in the last paragraph:
"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. Not only does this increase the value of the data model by allowing it to be reused for many parts of your overall solution, but it also allows us to invest more heavily in common tools which will streamline the development process, make developer learning apply to more scenarios, etc. ..."
Basically the Entity Data Models that are built using the Entity Framework are going to be the centerpiece of communications with several technologies. Its not that its better or worse than XYZ, its that it will collaborate better with other tools (some not yet built nor conceived).
Again, from Danny;s post ... "it's the first step in a much larger vision of an entity-aware data platform." I like this ... rolls off the tongue. Think about this example .. Silverlight applications need to communicate with other "places" to get their data. This could be a web service, a REST request, or even a POX (Plain Old XML) stream. Making data available via REST is becoming more abundant ... and with ADO.NET Data Services you can use REST to retrieve entities, because ADO.NET Data Services effectively handles the translation of the REST request to and from the entities in an Entity Data Model. So its a win win situation for Silverlight and for developers since we get to reuse our Entity Data Model and leverage our existing code.
Is it all perfect? Of course not. Does the Entity Framework fit for every situation? Of course not. But one thing is for certain ... Microsoft is making sure its technologies are EF aware.
