10

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 complicated 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: 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.

emallove
  • 1,417
  • 1
  • 17
  • 22
dtc
  • 10,136
  • 16
  • 78
  • 104

6 Answers6

12

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.

gfrizzle
  • 12,419
  • 19
  • 78
  • 104
8

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).

U62
  • 4,355
  • 1
  • 24
  • 37
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.

wasatz
  • 4,158
  • 2
  • 23
  • 30
3

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

Andrew Harry
  • 13,773
  • 18
  • 67
  • 102
  • I finally got around to doing a test and I was surprised in the opposite way. I have no idea if my test is valid, but I first delete 1000 records, add 1000 records, edit 1000 records and then databind them to a DataView. LinqToSQL: 5 seconds LinqToEntities: 2 seconds – dtc Dec 16 '08 at 01:29
  • 1
    DataSets? Ugh...There are plenty of other frameworks out there (e.g., Subsonic, NHibernate, etc.). Not to mention custom development, which I still often prefer. I have never come across a project that used DataSets that I considered even remotely clean. – senfo Dec 30 '08 at 03:08
  • Besides the performance test, you should also look at how much time and effort it takes you to make whatever framework do what you want. As senfo pointed out, DataSets may be fast, but they're not really that great to work with. – Wayne Bloss Feb 04 '09 at 08:40
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.

Tim Scott
  • 15,106
  • 9
  • 65
  • 79
  • I have not used NHibernate, but a former co-worker of mine had to switch from using Linq-to-SQL to NHibernate at his new employer and he hates it. In his opinion, NHibernate is far less powerful. – Sam Schutte Nov 14 '08 at 14:51
  • It's one thing to say that NHibernate is far less powerful. It's another to give examples as to why. It has been my experience that most people that don't like NHibernate later change their mind after learning more about it. – senfo Dec 30 '08 at 03:10
2

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?

marko
  • 10,684
  • 17
  • 71
  • 92
  • 1
    "the downside is sql strings"... that's why you would use a stored procedure instead of generating those strings! – ObiWanKenobi Dec 03 '10 at 06:18
  • SQL is not dead and when written correctly it can do very complex tasks extremely fast. But SQL is a low-level database access language. It is almost akin to assembly instructions to the CPU. It has vendor specific variations to improve performance that you need deep knowledge of the internals to achieve, and it has no concept of higher level concepts such as inheritance. But modern programmers are writing their programs in high-level languages such as C#. Why should you have to drop down to using the low-level instruction set? Access it as objects just like you do with anything else. – Mike D. Mar 18 '14 at 12:33
  • But don't get me wrong, I love SQL. It's an interesting language to solve problems in and you can do things to data that you just can't easily do in any other language. – Mike D. Mar 18 '14 at 12:41
  • It's a while ago that question was asked. I've come to embrace some of the ORM solutions out there - LINQ2SQL, Entity and NHibernate. But working with complex operations with databases, I think tyou will eventually need to write some sql. And when working with legacy applications where the existing codebase is largely made up by stored procedures, then you need also write some sql. And sql knowledge is still important to know, you need to know what happens under the hood. But I don't agree that is too low level - like as assembly. – marko Mar 18 '14 at 13:02
  • It's still uses the same entities as in OO-languages for example. a name is a column or in C# a property. So for this it's operating on the same level of detail, but in different way. SQL is setbased, whereas C# is a iterative programming language. It's different and has different strengths and weaknesses. – marko Mar 18 '14 at 13:10