21

So what's the verdict on these two products now? I can't seem to find anything regarding this issue SPECIFICALLY for VS2010/.net 4.0

Back in .net 3.5 days, most people believe Linq2SQL will be dead when .net 4.0 comes around, but it seems alive and well.

On the other hand, EF 4.0 seems to have gotten significant improvement.

For me, most of my work so far are small to medium sized projects, and my company is migrating from VS08 to VS10 soonish. What should I be looking at? Or really, should I spend the time studying EF4.0 or would it be time more well spent looking at nHibernate? (But back on topic, I'm really more interested in Linq2Sql - EF.)

Lastly, I am currently using entlib / unity, which framework is more friendly for dependency/policy injection?

Thanks in advance.

RPM1984
  • 72,246
  • 58
  • 225
  • 350
Sleeper Smith
  • 3,212
  • 4
  • 28
  • 39
  • does my below answer answer your question? If so, please tick it as the correct answer. – RPM1984 Dec 14 '10 at 22:25
  • 1
    TBH, I dunno if your answer is the right answer, but it certainly did give me some idea regarding which direction I should be looking at when comparing these two products. Thanks!. – Sleeper Smith Dec 20 '10 at 04:52

6 Answers6

26

Here are some reasons why Entity Framework (v4) is better:

1 - L2SQL is essentially obsolete

2 - L2SQL does not support POCO mapping, EF does.

3 - EF has more flexibility (code first, model first, database first). L2SQL has only 1.

4 - EF has support for SPROC -> POCO mapping

5 - EF has Entity-SQL, allowing you to go back to classic ADO.NET when required

6 - EF supports inheritance (TPT, TPH)

7 - EF goes hand-in-hand with Repository pattern, and deferred execution via IQueryable

8 - EF components (ObjectSet, ObjectContext) are easily mockable and allow for DI

I cannot think of any reason why new projects should use L2SQL.

Some might say "Well L2SQL is good for small projects, i can drag and drop and be done with it".

Well you can do that with EF4 as well, and you'll have more flexibility/support in the long run if you decide to modify/grow your project. So that is not an excuse.

HTH

RPM1984
  • 72,246
  • 58
  • 225
  • 350
  • 10
    L2SQL is much simpler to get started with, doesn't require a huge learning curve, and does what most small to medium projects need it to. That's why people choose L2S over EF. – Erik Funkenbusch Dec 01 '10 at 23:25
  • 5
    I disagree. It seems "simpler" because it doesn't have many features. But the act of dropping tables on a model and coding against it is basically identical between L2SQL and EF. "Add New Entity Data Model -> Generate From Database -> Include these tables". Done. Code against the DC generated by EF. That to me is pretty simple. – RPM1984 Dec 01 '10 at 23:30
  • 2
    What about the performance difference? When EF first came out, it's pretty horribly slow. – Sleeper Smith Dec 02 '10 at 01:54
  • 2
    We're talking about EF4 here, not EF1. – RPM1984 Dec 02 '10 at 02:01
  • Yeah, I'm not suggesting "performance difference" as a reason not to use EF. I'm asking if there are still actually much performance difference in EF4 and Linq2SQL. – Sleeper Smith Dec 02 '10 at 02:05
  • Not sure to be honest. I went from using L2SQL straight to EF4. I've never found issues with performance in either. At the end of the day both get translated to native SQL. What performance are you referring to? The time it takes to translate L2SQL/EFSQL -> SQL? – RPM1984 Dec 02 '10 at 02:40
  • Well, not really referring to any specific part of ORM in regard to performance, but there were a few performance tests floating around a long time ago saying CRUD operation is as much as 2 to 3x faster on L2s than EF. But then that was EF1.0 (edit - ef/l2s changed around) – Sleeper Smith Dec 02 '10 at 06:07
  • 3
    @Sleeper, don't believe every performance claim you read on the Internet. Write code for your specific problem and profile it. Premature optimization is death. – Craig Stuntz Dec 02 '10 at 13:49
  • EF4, the Code first is in CTP 5, unless there is another way? – dbones Dec 09 '10 at 18:21
  • 2
    Does anyone have any references for Linq To SQL being obsolete? – Russell Apr 09 '13 at 07:35
17

Just to add to the previous answers and comments (all three got a +1 vote from me):

a) Performance: the L2S runtime is more lightweight than EF (due to only a single layer; EF has to deal with two model layers and the mappings between them).

EF often generates a bit more verbose TSQL than L2S but most of the time that only affects readability if you're profiling and looking at the generated queries; the SQL optimizer will end up with the same execution plan most of the time. There are however some cases when the queries can grow so large and complex that it can have a performance impact.

L2S is also slightly better at doing client-side optimization of queries; it eliminates where clause predicates that can be evaluated client-side so the database don't have to worry about them. This means less work for SQL Server's optimizer, and less risk that you'll end up with a 'bad' execution plan.

b) L2S vs L2E: L2S is still slightly better than L2E at translating LINQ queries that use normal CLR methods into TSQL, especially when it comes to DateTime and methods related to it. L2E supports more or less the same things but through its' own EntityFunctions class: http://msdn.microsoft.com/en-us/library/system.data.objects.entityfunctions.aspx.

Both L2S and EF are great choices in my opinion, pick the one you feel comfortable with and covers the things you need now and during the reasonable lifespan of the code you're writing. Before you know it, Microsoft will probably announce yet another data access technology. They seem to do that every 3-5 years... :) DAO, RDO, ODBC, ADO, OLEDB, ADO.NET, typed datasets, ObjectSpaces, WinFS, L2S, EF, ... etc etc. Code I wrote 15 years ago against DAO is still out there, in apps that are still on the market, and it still works despite DAO being "dead" for years.

Sometimes names are reused for completely new data access technologies, but that doesn't change the fact that whatever constitutes Microsoft's latest database access technology is a constantly moving target...

KristoferA
  • 12,287
  • 1
  • 40
  • 62
4

I know this is probably too late for the original query, but for the sake of future people with a similar question...

To my mind, the crucial aspect is whether you're doing an entirely new project or working with a legacy DB. I'm working with a legacy DB, with some rather idiosyncratic design decisions. I'd like to use EF, but it simply failed to map over these idiosyncracies, while L2S managed perfectly well.

For example. Some of the FKs contained other values than keys to related rows - effectively doubling as an FK/flag column.

Further, the FK inheritance mapping totally failed against out DB, so I opted for a flat L2S model, to get the benefits of type-checking and name checking at query time, but ended building my own mapping layer.

All of this is a horrible pain, if its any consolation to MS, I also found NHibernate incapable of the task. In my experience, in real-world usage too many DBs have these kind of issues, hence my recommendation that EF is not really suitable for brown-field develop ment.

For new projects, you have the luxury of evolving your DB design to match the assumptions of the framework. I can't do that as existing applications rely on the data design. We're hoping to improve the design incrementally, but attempting to correct all the problems up front would result in an infeasibly large migration event (for our resources).

Note: In the UK (at least), brown-field development is building houses on land that has previously been developed. Green-field development is building on our dwindling resources of countryside. I've reused the terms here.

Rob G
  • 41
  • 2
4

L2S isn't going anywhere. The VS team has made that clear. It won't get significant improvement, but it will still be around and work just fine.

L2S is great, and easy to use for small scale projects with fairly simple data models. The trigger for me, when to choose EF over L2S is if I have many-to-many tables, or I need to map more complex entities over more than just a single table.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
3

We've just moved from VS 2008 to VS 2010 and from L2S to EF.

Even though we are using EF in a very similar fashion to L2S, it comforts me knowing that I have flexibility to do more advanced ORM should the need arise.

That said - for a small project - I would probably still use L2S. Medium to large projects I would use EF.

Also - EF seemed like a big learning curve, because the EF documentation prompted us to start investigating some design patterns like Unit Of Work, Repository, Dependency Injection. However I realised that these patterns applied to L2S as well as EF.

In terms of Nhibernate - my research (ie. browsing SO) indicates that the latest version of EF4.0 is sufficiently advanced (POCO support etc.) to be considered a competitive product.

dan
  • 5,664
  • 8
  • 45
  • 59
1

If third-party products are appropriate for you, try using LinqConnect. This product allows you to use Linq to SQL (with some modifications) with different DBMS (Oracle, MySQL, PostgreSQL, etc.).
LinqConnect offers you the following features unavailable in L2S earlier:

  • Model-First approach
  • TPT and TPH support
  • POCO support
  • Automatic synchronization of model and database without data losses.

As for performance, the latest comparative test on OrmBattle our provider is among leaders.

Also, all EF functions are supported in our DBMS-specific providers as well.

Devart
  • 119,203
  • 23
  • 166
  • 186