Entity Framework 4 vs LINQ to SQL, for small or me

Question

I've seen some discussion about L2S vs EF4 on Stack Overflow back in April, when VS2010 was launched, namely:

Dump Linq-To-Sql now that Entity Framework 4.0 has been released?

Is Entity Framework worth moving to for a new small app?

Now, after 6 months, presumably people have had more interacting with EF4, so I'm curious of fresh opinions, especially when considering working only with SQL Server.

I've used LINQ to SQL a lot, and only played a bit with EF4. I wouldn't mind jumping in and learning more EF4, I'm not convinced though that it's worth the extra complexity, if my app is only going to talk to SQL Server.

So, if you had some experience with both, and you were to start a new small or medium-size app today, with a SQL Server back-end, which one would you choose?

And, of course, why...

Answer 1

The company I work for is a $2.5B to $3.0B solar manufacturing company. We're using L2S for all of our next generation manufacturing applications. It's not without its warts, but we've found it to be fast (contrary to what many think), nimble and very easy to work with. We have no regrets. It does everything we need it to do.

Answer 2

In my opinion the future of LINQ To SQL is a bit unclear. I would personally go with Entity Framework as it provides the most flexibility and as it seems to be where Microsoft is directing the focus of their future development. I have been using Entity Framework and while it does have some quirks, I've been happy with it for the most part.

Answer 3

Nhibernate. Or BLToolkit for special cases. Linq2Sql and EntityFraemwork are still generations behind.

Answer 4

I'd go with Entity Framework in almost any case. Biggest downside is there is little way to tweak/improve your model once you go live without blowing the thing up and regenerating. That and EF can do anything you could do with l2s and more while having better tooling and such.

Answer 5

It depends... :)

If you don't need any of the extra features added by EF, L2S is generally:

• easier to get started with and work with,
• does more straightforward translations from Linq queries to TSQL and supports translating more plain .net methods into TSQL whereas L2E relies on 'special' methods for things like date/time comparisons etc,
• and has less runtime overhead due to the direct 1:1 mapping between tables and entity classes.

EF adds more features such as support for other RDBMSes and more complex mapping than plain 1:1, support for several different types of entity inheritance etc. That comes with a cost:

• the runtime overhead is higher than for L2S,
• writing linq queries against EF is slightly more likely to run into expressions that can not be translated into TSQL due to use of unsupported CLR methods, or that needs to use L2E's 'special methods', and
• it can take a bit more time to get the head around EF models than L2S models due to the dual layers (storage model and conceptual model) and the mappings between them. Manual tweaking of the model file in an xml editor is not unusual.

In short:

1. If your app is simple enough, you only need to support SQL Server, and your db schema / data model is clean enough so you don't need to do more advanced mapping then L2S is a great choice. Although it is unlikely that MSFT will add any new big features to it, that is not really necessary. It works great as it is and solves the problem it is supposed to solve. Lots of apps and websites (including this one) runs fine on L2S.
2. If you need to support other DBs than SQL Server, or if your db schema doesn't match the object model you want, or you need other 'bigger' features from EF then you should use EF.