LINQ查詢在EF 6.1

我使用EF 6.1與Visual Studio 2013的自定義對象的最佳實踐我有一個視圖模型LINQ查詢在EF 6.1

public class SaprePartsViewModel 
{ 
    public long ItemID { get; set; } 
    public string ItemCode { get; set; } 
    public string ItemName { get; set; } 
}

而且還具有數據庫表SapreParts具有相同的列名。

我已經完成了這兩種方法來獲取自定義對象

i。

var sqlQueryList = db.Database.SqlQuery<SaprePartsViewModel>(
    "select ItemID,ItemCode,ItemName from SpareParts").ToList();

ii。

var linqQueryList = db.SpareParts.Select(x => new SaprePartsViewModel 
     { 
      ItemID = x.ItemID, 
      ItemCode = x.ItemCode, 
      ItemName = x.ItemName 
     }).ToList();

這兩個查詢工作正常。但我的問題是哪一個使用？哪個是最佳的性能？

來源

2016-04-21 syed mhamudul hasan akash

我認爲由於涉及到如此多的度量標準，我認爲性能是一個如此困難的話題。對於上面的簡單查詢，顯而易見的答案是使用EF約定，因爲您可以免費獲得智能感知，並且使測試變得輕而易舉。根據sql查詢的靜態字符串會隨着時間的推移而中斷，查詢的主體也會隨着時間的推移而改變，所以你有一個移動的目標選項我去--iiii除非你有可測量的問題 –

賽跑跑道上的兩輛車找到哪一個更快移動 –

ShekharPankaj - 表現不僅僅是速度（imho）。這也是關於清晰的目的和易於維護。在蘇格蘭有一句老話：*速度更快，速度更快*。簡而言之，就是要平衡從查詢中減少幾毫秒的代價，同時讓工作代碼出門並易於維護。 –

[按我的意見OP]

我想表現這樣一個棘手的問題牽制，因爲有涉及這麼多的指標。對於上面的簡單查詢，顯而易見的答案是使用EF約定，因爲您可以免費獲得智能感知，並且使測試變得輕而易舉。

根據sql查詢的靜態字符串會隨着時間的推移而崩潰（壞，壞，壞!!）並且查詢的主體也會隨着時間的推移而變化（更糟，更糟，更糟糕），所以你有一個移動目標選項我 - 去ii，除非你有可衡量的問題。

順便說一下，性能不僅僅是速度（imho），它還關乎目的的明確性和易於維護。在蘇格蘭有句老話更急，速度更慢。簡而言之，可以平衡從查詢中減少幾毫秒的代價，同時使代碼出門並易於維護。你的團隊會感謝你（隨着時間的推移，你自己也會如此）

來源

2016-04-21 11:16:46

這個linq說了一個不同的單詞http://blog.codinghorror.com/compiled-or-bust/ –

如果你仔細閱讀，Jeff說明如下：*讓我們來做數學，儘管我吮吸它。每個未編譯的查詢運行時間不到三分之一毫秒。 - 因此，平均而言，通過犧牲使用linq查詢的可維護性，可讀性和可測試性，您可以節省1/3毫秒。你的來電：） –

LINQ查詢在EF 6.1

回答

相關問題