之前发现Ent上海网站建设ity Framework 4生成的COUNT查询语句问题，今天又发现它生成的分页SQL语句问题，而LINQ to SQL却不存在这个问题。
>>> 来看一看，瞧一瞧！
上代码：
看生成的SQL语句：
1. Entity Framework生成的SQL：
一个TOP，三个FROM。
上海闵行企业网站设计与制作2. LINQ to SQL生成的SQL：
无TOP，两个FROM。
两者的差距一目了然。
>>> 再来看一个：
将上面代码中Where的查询条件改为常量，即Where(coder => coder.Age > 20)，见下图：
然后看看生成的SQL。
1. Entity Framework生成的SQL：
明显不一样吧（颜色），实际上只是少了个exec sp_executesql，但会带来性能影响(sp_executesql will use cached plan to get more performance, 这里谈到了这个问题)。
2. LINQ to SQL生成的SQL与之前的一样。
Entity Framework考虑了多数据库支持、存储过程支持，却忽视了这个地方。
从LINQ to SQL的DataContext到Entity Framework的ObjectContext，然后又发布上海徐汇企业网站设计与制作a>ADO.NET Entity Framework Feature CTP5搞了个DbContext，DbContext也没有解决这个问题，感觉微软的思路有些乱。
目前看来，如果用Entity Framework 4，并在乎性能，只有两个选择：1. 不用LINQ to Entities，自己写SQL或存储过程；2. 自己写个Entity Framework ADO.NET provider for SQL Server 。
更新：从执行计划来看， Entity Framework生成的SQL似乎对性能没什么影响。
补充：
两个SQL的执行计划比较：
a) Entity Framework生成的SQL：
b) LINQ to SQL生成的SQL：
