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

　　>>> 來(lái)看一看，瞧一瞧！

　　上代碼：

　　看生成的SQL語(yǔ)句：

　　1. Entity Framework生成的SQL：

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

　　2. LINQ to SQL生成的SQL：

　　無(wú)TOP，兩個(gè)FROM。

　　兩者的差距一目了然。

　　>>> 再來(lái)看一個(gè)：

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

　　然后看看生成的SQL。

　　1. Entity Framework生成的SQL：

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

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

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

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

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

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

　　補(bǔ)充：

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

　　a) Entity Framework生成的SQL：

　　b) LINQ to SQL生成的SQL：

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

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