If I am using SQL Server as my database service, is there any compelling reason to look at LINQ to Entities over Linq to SQL?
+2
A:
Linq to SQL is no longer being actively developed - they are focusing their resources on Entity Framework. Also, EF is far more robust and allows for a number of more advanced scenarios that were overlooked in Linq to Sql.
While you are investigating ORMs, I would take a serious look at NHibernate. It has been around longer than either of Microsoft's offerings and is far more versatile.
Keith Rousseau
2010-01-29 18:20:57
L2S was enhanced (some) in .NET 4.
Craig Stuntz
2010-01-29 18:24:45
@Craig: what were the enhancements to L2S?
John Saunders
2010-01-29 18:30:32
@John Saunders http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40
Craig Stuntz
2010-01-29 18:35:14
@Craig: thanks.
John Saunders
2010-01-29 18:52:54
+1
A:
Linq to SQL is good enough if you only want a one-to-one mapping between your classes and tables, think of it as a “object” version of datasets.
EF lets you do a lot more complex mappings.
In the long term Microsoft is pushing everyone towards EF, however EF is more complex to use. Until .net 4 ships it is very hard to do test drive development with EF.
If you are going to hide all the data access behind a set of interfaces and create the domain objects yourself based on the rows you get from the database, then Linq to SQL is a good option in the short term. But you may be forced to move to EF in the long term.
If you wish to map your domain objects to your database using an ORM, then EF is a better object, however also also consider nhibernate
If you come back in a few years time the answer to your question would be EF, however it is not clear cut at present…
Ian Ringrose
2010-01-29 18:28:18
This depends on how you do TDD. If you do unit tests with an actual database, then that downside doesn't exist with EF.
John Saunders
2010-01-29 18:30:16
The answer to the question is actually NHibernate - unfortunately that's not an option for some shops.
Keith Rousseau
2010-01-29 18:31:06
@John - your unit tests shouldn't rely on a database unless you are actually testing the data access layer. It's slow and violates the whole idea of testing in isolation/
Keith Rousseau
2010-01-29 18:32:19
@Keith, NHibernate is not an good option if you wish to use Asp.net dynamic data, the new data server for Siverlight etc, as NHibernate does not do Linq well **yet**
Ian Ringrose
2010-01-29 18:36:43
@Keith: You test your way, I'll test mine. Small, quick, tests that include the database I have not found to be a problem. I don't unit test the UI, either.
John Saunders
2010-01-29 18:44:56
@John - You are technically doing integration testing if you are testing more than one thing at once. If data access is part of your test then you are testing more than one thing.
Keith Rousseau
2010-01-29 19:07:49
@Ian - Good point. I don't use dynamic data or most of the stuff that Microsoft puts out for that matter.
Keith Rousseau
2010-01-29 19:08:51
A:
There are so many compelling reasons to choose Entity Framework over LinqToSql, but you should need only one:
Microsoft would much rather you use Entity Framework. Microsoft is putting a large majority of their ORM development resources behind EF. That is their future road.
Unfortunately, EF 3.5 was a significant step back from LinqToSql in multiple ways so Microsoft really pushed a lot of people who wanted to use EF back to LinqToSql. With EF 4.0, EF is not completely feature equivalent to LinqToSql, but it's much closer.
EF 4.0 does offer many, many features that LinqToSql does not currently support and likely never will.
Stay away from EF 3.5 though. If you want an ORM for .NET 3.5, use NHibernate. For .NET 4.0, choose between NHibernate and Entity Framework. There is not really a good reason to use LinqToSql with .NET 4.0.
Michael Maddox
2010-01-29 20:31:57