之前發現Entity 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，然後又發佈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：
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
