之前發(fā)現(xiàn)Entity Framework 4生成的COUNT查詢語句問題，今天又發(fā)現(xiàn)它生成的分頁SQL語句問題，而LINQ to SQL卻不存在這個(gè)問題。

　　>>> 來看一看，瞧一瞧！

　　上代碼：

　　看生成的SQL語句：

　　1. Entity Framework生成的SQL：

　　一個(gè)TOP，三個(gè)FROM。

　　2. LINQ to SQL生成的SQL：

　　無TOP，兩個(gè)FROM。

　　兩者的差距一目了然。

　　>>> 再來看一個(gè)：

　　將上面代碼中Where的查詢條件改為常量，即Where(coder => coder.Age > 20)，見下圖：

　　然后看看生成的SQL。

　　1. Entity Framework生成的SQL：

　　明顯不一樣吧（顏色），實(shí)際上只是少了個(gè)exec sp_executesql，但會(huì)帶來性能影響(sp_executesql will use cached plan to get more performance, 這里談到了這個(gè)問題)。

　　2. LINQ to SQL生成的SQL與之前的一樣。

　　Entity Framework考慮了多數(shù)據(jù)庫支持、存儲(chǔ)過程支持，卻忽視了這個(gè)地方。

　　從LINQ to SQL的DataContext到Entity Framework的ObjectContext，然后又發(fā)布ADO.NET Entity Framework Feature CTP5搞了個(gè)DbContext，DbContext也沒有解決這個(gè)問題，感覺微軟的思路有些亂。

　　目前看來，如果用Entity Framework 4，并在乎性能，只有兩個(gè)選擇：1. 不用LINQ to Entities，自己寫SQL或存儲(chǔ)過程；2. 自己寫個(gè)Entity Framework ADO.NET provider for SQL Server 。

　　更新：從執(zhí)行計(jì)劃來看， Entity Framework生成的SQL似乎對(duì)性能沒什么影響。 

　　補(bǔ)充：

　　兩個(gè)SQL的執(zhí)行計(jì)劃比較：

　　a) Entity Framework生成的SQL：

　　b) LINQ to SQL生成的SQL：

NET技術(shù)：看看Entity Framework 4生成的復(fù)雜的分頁SQL語句，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。