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

Answer 1

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?

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

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 4

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 5

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 6

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.