Things to be aware of when moving from LINQ to SQL --> LINQ to Entities

Question

I have used LINQ to SQL successfully on an number of projects recently, but am keen to move to LINQ to Entities since this looks like the area that will be receiving more investment from Microsoft as they move to .NET 4.0 and beyond.

Before doing so I am keen to find out what things LINQ to SQL has that are missing from LINQ to Entities. My initial investigations have unveiled a couple of minor annoyances.

• LINQ to Entities does not support Single() or SingleOrDefault()
• LINQ to Entities will not allow you to inspect the generated SQL in the VS2008 IDE for a non-executed query

Does anyone know of any other such differences?

Note that I am not looking for a side-by-side comparison of the major features of LINQ to SQL and LINQ to Entities. I am hoping to learn about the more subtle differences that people have encountered.

Answer 1

• First/Take/etc; in EF, it requires (IIRC) an order; LINQ-to-SQL will accept these for an unordered query
• Sub-expression evaluation; if you have rolled a custom Expression (for example, predicate) using Expression.Invoke, it won't work; EF doesn't support sub-expression use (LINQ-to-SQL does)
• Serialization; very, very different
• Association loading; requires explicit Load in EF
• UDF support (composable at the database)

Answer 2

With EF, you can get the SQL that will be generated if you cast the query to ObjectQuery and then check the ToTraceString function. Granted, this isn't as easy as LINQ to SQL's implementation. Also, EF doesn't have a good logging interception option like the Context.Log in LINQ to SQL.

I'm doing a number of presentations on LINQ to SQL -> EF migration starting with VS Live next week and will be starting a blog series on it on thinqlinq.com soon.

Jim