How is the .net Entity Framework overkill versus LinqToSql?

Question

I've heard it said that the Entity Framework is overkill or that it's difficult to learn compared to LinqToSql.

I am wondering in what way? I used LinqToSql and like it. So, I am trying the EF and for the things I'm doing they seem almost exactly the same. Namespaces and method names are different but so far I don't see anything that makes the EF harder than LinqToSql.

I'm sure if I start doing more comples things it gets more complex. But then again I probably can't do the same thing with LinqToSql at all so I see that as a plus for the EF just in case I do want to do something more complex.

Does the EF use more resources than LinqToSql so much so that I should not use it if all I need is LinqToSql-like functionality?

Update: I did some tests and my tests seems to point to Linq to Entities performing better than Linq to SQL.

I first delete 1000 records from a single table, add 1000 records, edit 1000 records and then databind them to a DataView. LinqToSQL: 5 seconds LinqToEntities: 2 seconds

I performed the same test using two joined tables and the results were similar.

My tests seem to support another post: http://stackoverflow.com/questions/257016/linq-to-sql-vs-entity-framework-performance

Update 2:

Thanks for the replies. It appears to me that Linq to Entities isn't really overkill versus Linq to SQL. After researching more I think going with Linq to Entities is the way to go. It appears to have better performance.

I believe the "overkill" statements that I've heard are made because Linq to Entities can do much more than Linq To SQL and it does require more configuration (about 1 more line in the web.config). Also there are small things that Linq to Entities does differently from Linq to SQL that might make someone feel as though Linq to Entities is more complicated. But once you learn how to do things it seems Linq to Entities is no more complicated than Linq to SQL.

Answer 1

My answer: Do a simple comparsion of the time taken to perform a simple Get/Edit/Update sequence. I think you will find that LINQ to SQL is twice as quick. I did a quick comparsion project when i was investigating the differences.
The results where: Entity Framework 8,700 milliseconds LINQ to SQL 3,100 milliseconds Data-sets 2,000 milliseconds

So for me it was a simple question. Use DataSets or use Linq-Sql - Entity Framework didn't even factor into it!

link text

Answer 2

Correct me if I'm wrong, but the entity framework should only come into play when you need to transform the back-end objects, like when you're combining tables from different data sources, splitting tables, etc. It adds the entity layer so you can hide all the plumbing and just deal with your cleaned up entities. If you just use it 1 for 1 against your tables like you would in LINQ to SQL, then I'm sure that layer of complexity that you're not using will slow it down. It sounds like LINQ to SQL is the right tool for the right job in your case until you have more complex data source needs.

Answer 3

Before you dive in to Linq To SQL, check out this article by its program manager. He poses a straightforward question "Is LINQ to SQL Dead?" The answer is not as straightforward. It's definitely not "no." Sounds to me more like "probably maybe."

I would suggest before diving in to EF (now called Linq To Entities) you seriously consider NHibernate, but that's my personal bias.

Answer 4

Linq to SQL and Entity Framework are conceptually different beasts and you should make your choice based on how they fit your needs rather than on microbenchmarks. Even if Entity Framework was slower, it is the focus of the ADO.NET team at Microsoft and will be improved many times. Linq-to-SQL is effectively frozen.

Conceptually they are different in that Linq-to-SQL is just a way of performing database queries using Linq. Sounds obvious enough, but the point is: You are accessing the data, structured as per the database model of it. Although FKs are trasformed appropriately you still have excess objects where data was normalised into different tables. Every query you write has to cope with that kind of thing.

Entity Framework allows you to declaratively construct a layer that represents your data the way it should be represented in memory, bringing data from multiple tables into a single object where approriate; representing many-to-many relationships as collection properties, etc. And the queries you write then will be to this model and will be much cleaner and more obvious in purpose (no more 15 table joins!).

O'Reilly have a comprehensive book coming out Entity Framework on 15th Januray 2009 (preview available now on Roughcuts) if you're unsure about using Entity Framework - the MSDN documentation for it does pretty much suck at the moment which makes proposing it even harder. I do believe it's worth using in long run for all but the most trivial of projects (and personally if I was writing something trivial I'd just use ADO.NET2 directly and forget about Linq).

Answer 5

Be careful though, LinqToEntities can do some really interesting things if you use queries with - for instance - group by. I have never managed to get LinqToEntities to transform a group by into an actual SQL group by, it instead generates some massive code blocks which can be really ineffective.

For instance, check out the following link: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85-31d0b6a85f68

If you attempt to write "non-trivial" queries, ObjectQuery.ToTraceString() is your best friend to make sure that EF doesn't do something really stupid behind your back.

Answer 6

Why don't just do a ordinary SQL query with SqlDataReader and bind them to a Generic List. Seems like SQL is a lot more flexible and powerful than any ORM. In practice anyway!! Is SQL dead? And that must be the fastest approach, and the downside is sql strings, but you are working closer to the metal and feels like you have a lot more control than using any ORM. Feels like ORM:s always has some bug and makes more complex queries a pain in the ass and takes a lot longer to write than if you should done them in plain SQL. Or is it just me who are kind of new to ORM:s?