Linq2SQL vs EF in .net Framework 4.0_问答_开发者

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

开发者_JAVA百科

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.

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

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

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.

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.

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.

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: