之前發(fā)現(xiàn)Entity Framework 4生成的COUNT查詢語句問題，今天又發(fā)現(xiàn)它生成的分頁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考慮了多數(shù)據(jù)庫支持、存儲過程支持，卻忽視了這個地方。

　　從LINQ to SQL的DataContext到Entity Framework的ObjectContext，然后又發(fā)布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 。

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

　　補充：

　　兩個SQL的執(zhí)行計劃比較：

　　a) Entity Framework生成的SQL：

　　b) LINQ to SQL生成的SQL：

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

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