What makes The ADO.NET Entity Framework different than other ORM in the market?

Question

The question header is clear, i want to know why its different and why, when to select it for my project?

Answer 1

This is probably not the answer you are looking for but I dont think you should use it in your project. It is very young and not very complete. Wait until the next version comes out.

If you insist on using Entity Framework there are a few good things about it. A nice one is the way it allows for complex mapping in a very simple way. And of course because it is a microsoft technology the IDE integration is nice.

But like I said, I tried it and I dont beleive it is ready for real use.

Anyway good luck at your project

Answer 2

From what I've read, it has good support for WCF remoting/binary serialization, which is something many ORMs don't support very well (if at all). It might be worth looking into if you want to create a rich client/server/remoting app with ORM on the client side.

Answer 3

What different? It didn't learn from all the other ORMs.

Here are the issues I've been tracking for InfoQ

Does LINQ-to-Entities really return different results depending on previous queries?

Working Around Entity Framework's Large Data Model Issues

No Change Tracking for ADO.NET Entity Framework 2010

And this tool is a must-have if you do decide to use it.

Meta-data Synchronization Tools for LINQ to SQL and ADO.NET Entity Framework

Answer 4

ADO.NET is not an ORM.

Basically the difference is the level of abstraction used in each one.

With ADO, you basically query the DB and use the results as objects, is like a bridge between the RDBMS and your objects.

You model your DB and then you create object from that model. That's why it is an Entity Framework ( db entities )

ORM are not for querying or represent database records as objects ( although that's how everyones uses them anyway - me included - ) but a way to persist your object model into a relational database.

They are Object to Relational Mapping ( not Relational to Object Mapping )

So, you choose one or the other, when you have a domain ( object ) model and you want something to persist it ( to a RDBMS ) or when you have a entity model and you want to use it as objects in your app.

Answer 5

Some of the best talent in the ORM world in .NET seem to be working on projects such as NHibernate (free-open-source; I use it) and LLBLGen Pro (commercial).

NHibernate is the reigning standard for enterprise-quality full-scale multi-vendor ORM. NHibernate is also the reigning standard for a pure implementation of ORM, permitting you the developer to write domain models completely independently from the NHibernate infrastructure, and completely eliminating code-generated classes.

NHibernate may look scary at first. But it is actually fairly friendly once you work with it a bit, and work has been underway since July to make NHibernate nearly configuration-free.

Answer 6

I wrote a blog post on this a while ago. In short, it takes a fundamentally different approach to ORM than Hibernate, ECO, and the other ORMs that I have looked at. You may think this approach is better, worse, or unimportant, but if you look deep enough it's hard to dispute that it is different. But don't take my word on it. If you're really interested in this subject, I strongly recommend reading this technical paper and this interview in ACM Queue.