【发布时间】：2018-09-10 09:43:52
【问题描述】：
如果我有非常资源密集的 SQL 查询要写入数据库以获取数据。是否建议使用实体框架通过存储过程调用来获取数据，还是我们应该坚持使用 ADO.NET
【问题讨论】：
-
EF 可用于运行任意 SQL 查询（并将对任何结果进行行集到对象映射）：所以你可以。
标签： .net entity-framework stored-procedures ado.net
【发布时间】：2018-09-10 09:43:52
【问题描述】：
SQL 脚本就是一个 SQL 脚本，无论它是由什么人编写或生成的。如果您使用最佳代码实现存储过程，那么它将执行良好。如果您的脚本中有浪费的、不需要的操作，那么它的性能将不会很好。如果脚本是使用 Entity Framework 生成的并且运行良好，那么您在使用它时不会有任何问题。如果它不是那么好，那么你需要一个存储过程才能获得良好的性能。
当您怀疑Entity Framework生成的脚本是否执行良好时，您将需要执行以下步骤：
- 找出要执行的算法的复杂度
- 创建一些测试用例并根据复杂性找出预期的计算时间
- 如果计算时间低于预期时间，那么您将需要找出与启发式实验所经历的现实相比，您的预期为何如此悲观
- 否则，如果计算时间较长，则尝试在存储过程中自己实现相同的东西并比较性能
- 如果计算时间在预期时间左右，那么你不需要做任何事情，EF已经完成了任务
我很长一段时间没有使用 .NET 和 EF，但据我记得，在许多情况下，它倾向于一个接一个地收集记录，为每个记录执行单独的查询，即使它们可以由单个查询收集，这大大增加了复杂性。
因此，简而言之，EF 在许多情况下都表现良好，但如果您遇到缓慢，那么您需要找出其原因，如上所述。当单个脚本可以返回所有需要的 n 条记录时，您将需要检查生成的脚本以查看它是否编写了 n 个脚本来获取 n 条记录。在这里您可以看到收集生成的查询的方式：How do I view the SQL generated by the Entity Framework?
【讨论】：
-
我完全承认你提到的所有指针。它几乎回答了大多数场景的问题。但是考虑一个 SQL 查询，它需要 10-12 个表连接或需要一些表透视，或者获取数据集的 Dense_Rank、Rank 或 RowNumber（这些功能易于使用并且在 SQL 中进行了优化）。您是否仍然建议使用 Linq 进行 EF 代码，我觉得编写和完成它会很麻烦？
-
@MausamMalviya 我在 LINQ 中编写了性能非常好的代码，这些代码非常长，至少涉及 15 个表，并且在几年前进行了非常复杂的计算，并且代码性能非常好。但是，我有一个几乎相似的稍微不同的任务，但细微的差异是 LINQ 无法很好处理的，所以我不得不实现查询。我的观点是 LINQ 对 90% 以上的查询都有好处，当您没有预见到性能问题时，使用 LINQ 是个好主意。
-
@MausamMalviya 如果这种乐观主义没有产生结果，并且 LINQ 对于给定的查询是一个糟糕的选择，那么我认为这不应该被视为失败或损失，而是一个理解的机会LINQ 的一个普遍缺点，它将缩短您未来的斗争，并从长远来看会使事情变得更容易。但是您需要慢慢来，真正理解为什么 LINQ 表现不佳。至少我在给定的团队中是这样工作的，并且在那里取得了相当大的成功。
-
@MausamMalviya 总结一下：如果您知道某个查询由于以前的经验或其他信息而不能很好地执行，那么立即从存储过程开始。如果不是，那么使用 LINQ 是有意义的，就好像它没有性能缺陷一样，那么编写好的 LINQ 查询可以以非常智能的方式重用，以解决更复杂的问题，作为不同 LINQ 查询的一部分，而存储过程的可重用性并不那么容易.
-
您的方法令人印象深刻。这将有助于减少（人们通常对使用 LINQ 和 EF 进行复杂查询的怀疑）。
EntityFramework/EntityClientDataProvider 的主要职责是将 LINQ-to-Entities 或 Entity SQL 查询转换为底层数据库可以理解的 SQL 查询。它与 ADO.Net 数据提供者通信，后者反过来从数据库发送或检索数据。最后，它使用 ADO.Net Data Provider 与使用标准 ADO.Net 的数据库进行通信
所以你的问题的答案是：它不会改变计算的功耗。
查看 EF 架构图。 EF Overview
【讨论】：
-
我担心使用 EF 对复杂查询的性能影响。这就是为什么我提到“是否推荐”在这种情况下使用EF。