实体框架运行存储过程和本机查询性能注意事项答案

【问题标题】：Entity framework running sprocs and native queries performance considerations实体框架运行存储过程和本机查询性能注意事项
【发布时间】：2011-03-15 12:52:37
【问题描述】：

我想知道在执行以下操作与使用普通的旧 ado.net DataReader 和 DataTable 时是否会降低性能：

using(DBEntities dbEntities = new dbEntities)
{
    ObjectResult<tblCustomers> customers =
        dbEntities.ExecuteStoreQuery<tblCustomers>("SELECT name,id FROM tblCustomers");
}

我还想使用 dbEntity 运行存储过程。

我之所以提到这一点，是因为我正在开发一个对性能敏感的应用程序，但仍想使用实体框架。

此外，谁能指出我最近在 .net 4.0 上对实体编译查询的 linq 性能测试？

编辑
如果我使用 ado.net，我计划将我从每一行获得的结果手动插入到 .net 对象中。所以它是实体框架 storequery/sproc vs ado.net + 手动创建和插入数据到 .net 对象。

【问题讨论】：

标签： c# .net asp.net linq entity-framework

【解决方案1】：

是的，当然 - 这是比普通 ADO.NET / SQL 更高级别的方法。

您发送一个 SQL 查询并返回一个 tblCustomers 对象列表。沿着这条线的某个地方，会发生从数据库的行/列到对象的映射，这确实需要一些时间。

另一方面 - 如果你想自己做同样的事情，你也必须支付性能损失 - 或者你只是使用旧式的行/列来做你的工作（不是推荐！）。

这是经典的“便利性与性能”权衡 - 对您来说更重要的是什么？能够使用漂亮的 C# 对象及其属性进行编程，并且作为程序员非常有效率 - 或者从数据库中的 SELECT 几纳秒？这是你的选择......

【讨论】：

如果我使用 ado.net，我当然计划将结果插入对象，也许我不够清楚，我的意思是运行查询本身而不是时间的性能损失需要将其转换为对象（正如您提到的那样可以忽略不计）。
@dortzur：我没有任何数据来支持这一点，但你几乎可以假设微软会尽其所能尽快完成这些事情——通常，“做它自己”几乎无法更快地工作 - 除非您可以利用通用方法不可能拥有的有关系统的一些信息。
@dortzur：在幕后，我很确定这段代码也使用 ADO.NET 连接和DataReader 来获取其数据 - 真的不能比这快得多。 ..
由于我们不知道性能要求、环境或 OP 实际尝试使用他检索的数据实现什么，因此您的 not 推荐评论假设很多。您是否建议上课总是比仅使用行更好？我怀疑在大多数情况下您是正确的，但不一定总是正确。