Linq to Entities與ESQL的性能

entity-framework entity-sql linq-to-entities

使用實體框架時,ESQL的性能是否優於Linq to Entities?

我更喜歡使用Linq to Entities(主要是因為強類型檢查),但我的其他一些團隊成員都將性能作為使用ESQL的理由。我想充分了解使用這兩種方法的專家/騙子。

一般承認的答案

最明顯的區別是:

Linq to Entities是強類型代碼,包括很好的查詢理解語法。事實上,“from”來自“選擇”,允許IntelliSense幫助您。

實體SQL使用傳統的基於字符串的查詢,使用更熟悉的SQL語法,其中SELECT語句位於FROM之前。因為eSQL是基於字符串的,所以動態查詢可以在運行時使用字符串操作以傳統方式組合。

不太明顯的關鍵區別是:

Linq to Entities允許您使用“選擇新{...}”語法更改形狀或將查詢結果“投影”為您需要的任何形狀。匿名類型,C#3.0的新手,已經允許這樣做。

使用Entity SQL無法進行投影,因為您必須始終返回ObjectQuery <T>。在某些情況下,可以使用ObjectQuery <object>,但是您必須解決.Select始終返回ObjectQuery <DbDataRecord>這一事實。見下面的代碼......

ObjectQuery<DbDataRecord> query = DynamicQuery(context,
        "Products",
        "it.ProductName = 'Chai'",
        "it.ProductName, it.QuantityPerUnit");

public static ObjectQuery<DbDataRecord> DynamicQuery(MyContext context, string root, string selection, string projection)
{
    ObjectQuery<object> rootQuery = context.CreateQuery<object>(root);
    ObjectQuery<object> filteredQuery = rootQuery.Where(selection);
    ObjectQuery<DbDataRecord> result = filteredQuery.Select(projection);
    return result;
}

這里這裡 ,其中一個團隊成員詳細描述了其他更微妙的差異。


熱門答案

ESQL還可以生成一些特別惡毒的sql。我不得不跟踪這樣一個使用繼承類的查詢的問題,我發現我的pidly-little ESQL 4行被翻譯成100000個字符的怪物SQL狀態。

與Linq和編譯代碼相同的事情是更加可管理的,讓我們說20行SQL。

另外,其他人提到的,Linq是強類型的,雖然在沒有編輯和繼續功能的情況下調試非常煩人。

廣告



許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因