Look at the complex page-Entity SQL statements generated by the Framework 4

The count query statement generated by entity Framework 4 was previously found to be a problem with the paging SQL statement that it generated today, and LINQ to SQL does not.

>>> take a look, and see!

Code on:

Look at the generated SQL statement:

1. SQL generated by the Entity framework:

A top, three from.

2. LINQ to SQL generated sql:

No top, two from.

The gap between the two is clear.

>>> look at one more:

Change the query condition of the Where in the code above to a constant, where coder => coder. Age > 20), see figure below:

Then look at the generated SQL.

1. SQL generated by the Entity framework:

It's obviously not the same (color), but it's actually just a few exec sp_executesql, but it's going to have a performance impact (sp_executesql will-use cached-get-more configured, here's the problem).

2. LINQ to SQL generates the same SQL as before.

The Entity framework takes into account multiple database support, stored procedure support, but ignores this place.

From the DataContext of LINQ to SQL to the ObjectContext of the Entity framework, and then the Ado.net Entity framework Feature CTP5, DbContext also did not solve the problem, feeling that Microsoft's thinking a bit messy.

Now it seems that if you use the Entity Framework 4 and care about performance, there are only two choices: 1. Write your own SQL or stored procedure without LINQ to Datastore; 2. Write your own entity Framework ado.net provider for SQL Server.

Update: From the execution plan, the SQL generated by the Entity framework appears to have little impact on performance.

Added：

Two SQL execution plan comparisons:

A Entity framework-generated SQL:

b The SQL generated by LINQ to SQL: