What makes the ADO.NET Entity Framework different from other ORMs on the market?

Question

The title of the question is clear, I want to know why it is different and why, when to choose it for my project?

Answer 1

I wrote a blog post about this a while ago . In short, it takes a fundamentally different approach to ORM than the Hibernate, ECO, and other ORMs that I looked at. You might think that this approach is better, worse, or unimportant, but if you look deep enough, it’s hard to dispute that it is different. But do not come to terms with this. If you are really interested in this question, I highly recommend reading this white paper and this interview in the ACM lineup.

Answer 2

This is probably not the answer you are looking for, but I don’t think you should use it in your project. He is very young and not very perfect. Wait until the next version comes out.

If you insist on using the Entity Framework, there are a few good things. The good thing is that it allows complex display in a very simple way. And of course, because it's Microsoft technology, IDE integration is good.

But, as I said, I tried it, and I do not believe that it is ready for real use.

Anyway, good luck with your project

Answer 3

From what I read, it has good support for remote / binary WCF serialization, which many ORMs don't support very well (if at all). It might be worth a peek if you want to create a rich client / server / client-side ORM remote connection application.

Answer 4

ADO.NET is not an ORM.

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

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

You model your database, and then create an object from this model. This is why it is Entity Framework (db objects)

ORMs are not designed to query or represent database records as objects (although the fact that they all use it anyway turned me on), but a way to store your object model in a relational database.

They are objects for relational mapping (not tied to object mapping)

So, you choose one or another option when you have a domain (object) model, and you want something to save it (for an RDBMS) or when you have an entity model, and you want to use it as objects in your Appendix.

Answer 5

What is the difference? He did not learn from all other ORMs.

Here are the issues I tracked for InfoQ

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

Work with large entities of the Entity Framework model

No change tracking for ADO.NET Entity Framework 2010

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

Metadata Sync Tools for LINQ to SQL and ADO.NET Entity Framework

Answer 6

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

NHibernate is the current standard for full-blown ORM with multiple vendors. NHibernate is also the standard for a clean implementation of ORM, allowing the developer to create domain models independently of the NHibernate infrastructure and completely eliminate the classes generated by the code.

NHibernate may look scary at first. But in fact, he is quite friendly when you work with him a little, and since July he has been working to make NHibernate practically without any configuration.