Danny Simmons, a Microsoft developer for ADO.NET Entity Framework project, has recently written a blog post comparing the Entity Framework with other data access solutions. After comparing it with the traditional ADO.NET and LINQ to SQL, Danny puts the Entity Framework against nHibernate, prompting other developers to react. This is an excerpt of Danny's post:
The big difference between the EF and nHibernate is around the Entity Data Model (EDM) and the long-term vision for the data platform we are building around it. The EF was specifically structured to separate the process of mapping queries/shaping results from building objects and tracking changes. 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. ... So the differentiator is not that the EF supports more flexible mapping than nHibernate or something like that, it's that the EF is not just an ORM--it's the first step in a much larger vision of an entity-aware data platform.
As a reaction, Frans Bouma, the man behind LLBLGen Pro and a Microsoft MVP, has written on his post:
I don't get this: a person like Danny Simmons who worked on the Entity Framework for so long, how can such a person ignore the fact that any O/R mapper is about entity awareness? What's described in that last sentence is exactly an O/R mappers sole purpose: it's there so that the developer can work with entity instances in the OO language and store these instances in a non-OO environment like a relational database and vice versa. What larger vision is there to have, if all there is is the abstract entity model and its projections? Tooling perhaps? To make things easier for the developer to create these projections and position the O/R mapper service in the application code?
Jeremy D. Miller, a .NET developer and architect, said on his blog about Danny Simmons:
He left out the crucial fact in any consideration of using NHibernate versus the Entity Framework. The Entity Framework is very intrusive into your application, but NHibernate is not. NHibernate lets me use POCO's to model the business process in a database agnostic way. The Entity Framework wants me to bake EF infrastructure directly into my business objects.
Danny Simmons mentioned the benefits of using the EDM for other purposes like reporting, being commented by Greg Young, a Microsoft MVP, on his blog:
A single model cannot possibly be appropriate for all facets of your application including transactional behaviors, searching, and reporting. ... Let me say for the 1000th time. If you are reporting off your transactional model you are seeking trouble!
Jimmy Bogard, a senior consultant with Headspring Systems, had his reaction on his blog:
I think it's a mistake to share a data model with anyone outside your bounded context (see Evans, Domain-Driven Design). It's also a mistake to share a conceptual model or a EDM or whatever we're calling this.
I never want domain objects exposed directly via services. That's violating the encapsulation I'm trying to create.
If someone wants SSRS, then I give them a separate reporting database, tailored to reporting needs. I don't want reporting concerns bleeding into my transactional concerns. A mapping layer will not solve this problem, products like SSIS can. You want reporting? Here's your read-only view, updated every hour, five minutes, daily, whatever.
So, the question is this: is the ADO.NET Entity Framework more than just an O/R Mapper, and how it compares to nHibernate? Many tend to say that EF is simply an O/R mapper, and that it lacks many features compared to nHibernate. On the other hand, Danny Simmons says that Microsoft has just started with EF, and has plans for its future beyond its current O/R mapping functionality.