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.
Community comments
Jimmy Bogard hits the nail on the head.
by Rob Eisenberg,
Re: Jimmy Bogard hits the nail on the head.
by Ali Motaz,
Re: Jimmy Bogard hits the nail on the head.
by Francois Ward,
Re: Jimmy Bogard hits the nail on the head.
by Patrik Löwendahl,
Quick to Bash, Slow to Think...
by Timothy Khouri,
Re: Quick to Bash, Slow to Think...
by Jeff Santini,
Re: Quick to Bash, Slow to Think...
by Timothy Khouri,
Re: Quick to Bash, Slow to Think...
by Greg Young,
Re: Quick to Bash, Slow to Think...
by Timothy Khouri,
Re: Quick to Bash, Slow to Think...
by Frans Bouma,
Jimmy Bogard hits the nail on the head.
by Rob Eisenberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
"I think it's a mistake to share a data model with anyone outside your bounded context"
Of all the comments being made, I think this is the key. It seams that Microsoft's whole argument is based around the reuse of the EDM. However, we know from experience that most of the time you cannot reuse your models in other contexts. They just don't work well. In the remaining scenarios you don't want to reuse your model. Jimmy clearly notes that this breaks fundamental design principles such as encapsulation.
So, if its not really possible to reuse the EDM or even wise, doesn't that aspect of EF just add a huge amount of unnecessary complexity? And if Microsoft strips out that unnecessary complexity aren't we just left with an O/R M that functions like all the rest? Only compared to various existing solutions, this "new and improved" EF will have far less features.
Re: Jimmy Bogard hits the nail on the head.
by Ali Motaz,
Your message is awaiting moderation. Thank you for participating in the discussion.
I believe that with the EDM microsoft was trying to reduce the problem of have to deal with multiple datasources
So they created EDM which i thing of as a Meta-Data Model that can abstract all those different data source
I thought this would mean, I can either access the data source from the metea-data model, this would be perfect for something like SSRS.
Or directly, this could be better for a data entry application
Anyway seeing statements like "If someone wants SSRS, then I give them a separate reporting database, tailored to reporting needs." ... I am not sure what to think?
I dont see anything wrong with reporting against an online transactional DB! I can't even see anyone can, if a user can see a record after he entered it, thats a report, truely it is , I dont know why "Jimmy Bogard, a senior consultant with Headspring Systems" would prefer for him to wait 5 minutes or even a minute to see it!
If online-transactional reporting are eating your resources, do use SSAS (Analysis Services), but otherwise I dont see how its a bad thing.
Re: Jimmy Bogard hits the nail on the head.
by Francois Ward,
Your message is awaiting moderation. Thank you for participating in the discussion.
You hit it.
Microsoft is seeing the Entity Framework as the layer about your data tiers.
In a complex application, you'll have something like (im simplifying): A business layer, on top of high level data layer (or low level business layer, whatever you wish) that aggregate data from all possible datasource, then all of your data layers.
The entity framework is meant to replace that interim layer that so many projects forget about, or simply do not need (so the BLL calls the DAL directly, for example). Of course, most projects will have only 1 data store, and many will want to map entities to the data store 1:1, so ORMs in general, and Entity Framework by default (and almost exclusively, at release) do that.
But if the entity framework was feature complete by its vision, you could maps entity operations to Hibernate (a bit like LINQ to Hibernate), LLBLGEN Pro, stored procedures, SSIS packages, XML, web services, etc, and then query only one model. Thats the difference. (And I can picture some JOIN operations in that...would be quite funny).
For now, since its young and more theory than practice, ADO.NET Entity Framework providers map to SQL and stored procedures, putting it as "yet another ORM" and little more (at least its better than LINQ to SQL...).
Re: Jimmy Bogard hits the nail on the head.
by Patrik Löwendahl,
Your message is awaiting moderation. Thank you for participating in the discussion.
The question is this, does everybody understand the full strategy behind EDM? And would you rather have Typed DataSets as the Microsoft preferred application model of data? The EDM and EF are separate things, the EDM is for creating models and the EF is the ORM. The architecture of EDM / EF is layered and separated in such a way that it is possible to build your own ORM above the EDM (or maybe create a NH dialect / provider). I don't suggest that that's the first thing you should runaway and do, but this clearly shows that the intentions of the EDM is far broader then that of the EF.
A sum-up:
www.lowendahl.net/showShout.aspx?id=207
Quick to Bash, Slow to Think...
by Timothy Khouri,
Your message is awaiting moderation. Thank you for participating in the discussion.
1) EF has a long way to go, but it will likely be a good (possibly great) product.
2) I always enjoy seeing ignorant, emotional comments like "perhaps because Microsoft thinks it's an open source framework which isn't owned by any company"
3) Yes, I'm prepaired to be hated on for my above comments.
Re: Quick to Bash, Slow to Think...
by Jeff Santini,
Your message is awaiting moderation. Thank you for participating in the discussion.
re: "3)" But are you prepared to back them up?
What reason do you give for thinking EF is likely to be "good(possibly great)"?
Re: Quick to Bash, Slow to Think...
by Timothy Khouri,
Your message is awaiting moderation. Thank you for participating in the discussion.
@Jeff - Excellent question... and the answer is a simple one, so here it is:
I believe that EF is likely to be good (and possibly to be great), NOT because of what it is now, but simply because I expect MS to take this feedback, slap some money on the team and eventually (v2?) come out with a much better product than what it is now.
Does that mean that it will be better than LLBLGen, nHibernate or other OR/Ms out there? Well it certainly isn't now... but I don't think that's the focus anyway (to be 'better' than others). I think the focus is (or at least should be) to provide great functionality that has been proven in the community for years.
I don't want to go on a rant... so I'll ask: Does anyone disagree with me that with enough resources, and responding to feedback in a constructive way, MS can make this product good (possibly great)?
Jeff, the community needs more people like you :)
Re: Quick to Bash, Slow to Think...
by Frans Bouma,
Your message is awaiting moderation. Thank you for participating in the discussion.
"2) I always enjoy seeing ignorant, emotional comments like "perhaps because Microsoft thinks it's an open source framework which isn't owned by any company" "
I'm glad I made your day a paradise of enjoyment, Timothy ;)
Btw, it wasn't an emotional nor ignorant comment. If of all the points made in my long post, you could only pick that single phrase, I'd like to suggest to re-read what I wrote and what my point was.
I don't deny that the EF can possibly be a great product. That's not the point I was trying to deny/debunk. My point was that the EF isn't the great, 'look no further, the solution is here'-kind of product as some people seem to see it. Without much cold-hard facts, if I might add.
Re: Quick to Bash, Slow to Think...
by Greg Young,
Your message is awaiting moderation. Thank you for participating in the discussion.
"I believe that EF is likely to be good (and possibly to be great), NOT because of what it is now, but simply because I expect MS to take this feedback, slap some money on the team and eventually (v2?) come out with a much better product than what it is now. "
I think you will find an issue in this. The EF is about to be released with sp1. Once it is released the issue will become backwards compatibility. You are unlikely to see drastic re-architecting of it as a product after this point.
Cheers,
Greg
Re: Quick to Bash, Slow to Think...
by Timothy Khouri,
Your message is awaiting moderation. Thank you for participating in the discussion.
@Frans - I wanted to mention that I did enjoy your post, and I think that you brought a lot of great points to the table. My picking on that sentense in particular was to point out that we should be careful not to throw out non-issue, non-important statements when making an argument. If you pull out those types of lines, the reasoning is much, much stronger.
@Peter - You mentioned that EF would be better if there was "an open development process and feedback loops with the developer community." - I agree 100%, and that was my point in saying "responding to feedback in a constructive way."
So it sounds like we agree.
I think you misunderstood my point of the "money and developers" part... that was to state that Microsoft has the ability to provide the resources necessary to build a great product. That ability is not in every company (many places only have the luxury of "one shot").