entity-framework - Entity Framework 4.1 代码优先性能意见

Question

我首先使用 Entity Framework 4.1 代码，没有存储过程。我想知道关于它在大型应用程序上的性能的一般意见，因为它在后台生成 SQL。这不违背不使用存储过程的最佳实践吗？你如何微调这些生成的代码？

我知道你可以破解它来使用存储过程，但是肯定会支持存储过程和你通过数据库第一个选项获得的其他功能？

EF 4.1 对数据库第一选项有什么改进吗？我如何知道我是否拥有最新版本的 EF？

Answer 1

生成的 SQL 相当有效，但尽管我还没有使用 SP，但我已经编写了一些 View (在 4.0 中)并针对某些地方编写了 LINQ，以克服一些性能问题。

4.1 是否违背了存储过程的最佳实践？好吧，出于多种原因，SP 是最佳实践 - 性能是一个，从代码中隔离和抽象底层表结构是另一个。出于对我来说不是 100% 闻起来的原因，这部分的性能似乎已被放弃为“这些天可能不那么重要”。以及抽象问题 - 您使用 EF Code First 是有原因的 - 原因是您正在为您的应用程序对象寻找持久性框架:通过选择 EF Code First 的行为，您声明您没有想知道它们是如何存储的，在什么结构中，以及如何将它们取回。

你是怎么调的？主要是通过对延迟加载非常小心，通过监视 SQL 端发生的事情(EFProf 是一种工具，MSSql 查询分析也可以工作)并且通常通过摆弄事情。

为确保您运行的是最新的 EF(如果您一直在运行 CodeFirst CTP)，请使用 NuGet 控制台并

uninstall-package EFCodeFirst
install-package EntityFramework

4.1 对数据库优先于 4.0 进行了改进 - 即轻量级 dbContext

编辑:按要求添加代码...
简单案例

 foreach (var order in orders) y=order.orderlines.tolist();

你修复的

foreach (var order in orders.Include("orderlines").tolist()) y=order.orderlines.tolist();

但不太明显的是

foreach (var order in orders.Include("orderlines").tolist()) dothing(order);

在哪里

public void dothing(Orderline ol)
{
    if (ol.order.property=true)
    ....
}

解决这个问题，我认为你需要

foreach (var order in orders.Include("orderlines.orders").tolist()) dothing(order);

(或者更好的是将 dothing(Orderline ol) 重构为 dothing(Orderline ol, Order ord)。我的观点是，使用本地数据库非常容易错过这些。只有当您分析 sql 或连接到 SQL 数据库时一个缓慢的网络(想想 Azure)或者只是得到了严重的负载，这开始受到伤害!