实体框架 1 与。普通 SQL 应用程序答案

【问题标题】：Entity Framework 1 Vs. Normal SQL app实体框架 1 与。普通 SQL 应用程序
【发布时间】：2009-07-27 18:58:58
【问题描述】：

有谁知道使用 Entity Framework 而不是 SQL 普通应用程序的查询之间是否存在速度差异？使用实体框架，我们必须手动处理表之间的连接，在我看来，这似乎是一个相当复杂的查询。

假设一个客户在州/省、订单、性别、评论、收藏产品等方面有很多联接。假设有 15 个关系。执行显示信息的简单“查看”页面大约需要 3 或 4 秒。对于我和我的老板（呵呵）来说，这肯定需要 TOO 很多时间。

如果我用普通的SQL写这个，会不会更快？

【问题讨论】：

这取决于您是否在乎专业。没有证据就责怪一个软件是不专业的。
当然你可以责怪它..你也可以责怪硬件，或者网络。要知道真正的原因是什么，您可能应该进行一些分析并比较性能。在常规 SQL 和实体框架之间。
我一点也不怪它！！我想知道是否有人听说过这个插件的性能不佳。因为我认为它在 VS.net 2010 上工作得很好，他们修补了很多东西。但是 Framework 1.0 就像 beta 版本一样。
这也不是很专业。根据传闻做出决定。

【解决方案1】：

最好使用分析器来确定瓶颈在哪里。请记住，在大多数情况下，足够快 = 足够好。如果考虑到进行查询的上下文可以接受 3 或 4 秒，则不要理会。p>

过早的优化是一种能量的腰部。 - 值得深思。

【讨论】：

我在本地调试时试过这个。这需要不到 2 秒的时间。 1,2 秒正好执行我所有的页面进程。我看到它的最大更新时间为 2,3 秒。也许是因为我们的网络主机，因为它似乎比本地多花 1 或 2 秒。对不起我的英语，我知道它不太好。

【解决方案2】：

查询中的连接数表明它们可以写得更简单。无论您是通过实体框架还是使用 SQL 数据阅读器运行具有这么多连接的查询，它们都会运行缓慢。

【讨论】：

【解决方案3】：

我们发现，在使用 LINQ 在上下文中创建查询时，手动加载属性而不是使用 .Include 时，它的速度要快得多。现在，即使对于拥有 17 条关系的大型实体，我们的所有请求也只需要不到 2 秒的时间。

我们还发现对于小型实体，.Include 和 LoadProperty 之间没有显着差异，但是当您使用超过 10 - 12 关系的实体时，就有点棘手了。

坦克的回答和......哼，对不起我的英语！我尽力了！

【讨论】：