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

回答

相关问题