我们在首次运行 linq to EF 查询时花费了很长时间。我很惊讶地发现预生成视图后没有任何差异。我遇到了以下声明堆栈溢出
视图生成仅对“标准”查询有帮助（例如，当您调用 someObject.RelatedEnd.Load() 或 MyContext.SomeSetName() 时。由于显而易见的原因，它对使用 LINQ 或 ESQL 的即席查询没有帮助。使用 CompiledQuery 来优化那些。
当他说“出于明显的原因”时，我不得不说，“好吧，对我来说还不是很明显”。如果我理解正确的话，他声称 Linq to SQL 查询不受预生成 EF 视图的影响。
我曾认为实体视图是实体和表之间的通用映射，与任何特定查询没有关系。这是错误的吗？
我可以看到第一次运行 Linq to Entities 查询时使用了大量时间，此后时间大大减少，因此我假设正在为相关实体和表生成视图。如果它不是可以在第一次运行时预先生成的 EF 视图，那么它是什么？
所以我的问题分为三个部分：
EF 视图是为每个查询生成的，还是只是将表与实体相关联，而不管进行的查询如何？
上述关于预生成 EF 视图对 Linq to EF 查询没有影响的说法是否正确？是否必须使用 CompileQueries 来代替？
- 上面提到的“明显原因”是什么？
注意：我什至不会问，但如果您使用 EF，互联网上（包括 msdn）上有很多关于预生成视图的建议。这是我看到的唯一一个地方，它建议如果您使用 Linq to Entities，那么预生成与您的查询无关。
我认为您找到的答案不正确。您可以将 EF 视图视为一种抽象数据库的方式，以便 EF 可以在不了解实际数据库的情况下完成其工作。因此，EF 需要针对通过 EF 查询/更新管道的任何查询或修改操作的视图。事实上，任何/所有 EF 查询（无论是 Linq 查询还是 ESQL 查询）都是通过组合基本查询（实际上是视图）来构建的。
回答您的问题：
- 视图通常在第一个查询时仅生成一次
- 编译查询和视图是正交的 - 我在上面解释了视图，编译查询是为了缓存查询生成的 SQL，以避免再次编译查询。这很有帮助，因为应用程序中使用的一组查询通常是有限的，因此可以缓存生成的 SQL（请注意，如果将参数传递给查询，这不会影响生成的 SQL，因为它也会被参数化）。从 EF5 开始，缓存会自动发生（http://blogs.msdn.com/b/efdesign/archive/2011/06/30/auto-compiled-linq-queries-entity-framework-june-2011-ctp.aspx).
EF6 中对视图生成进行了许多改进。我想说的是，在绝大多数情况下，您根本不必使用 EF6 的预生成视图（我是作为 EF6 的作者这样说的）用于生成视图的 T4 模板对于 EF5 和 EF6 以及EF6 的交互式视图）。然而，我们发现对于 EF6 中的 Code First 应用程序，实际瓶颈在于构建模型。还有一些其他性能问题 - 请参阅这篇博文更多细节。许多此类问题已在 EF6.0.2 中得到修复，因此如果您尚未升级到 EF6.0.2，您应该升级到 EF6.0.2。我认为 EF 6.1 中还有一些与性能相关的修复。
边注：
注意他说的LINQ or ESQL并不是Linq to SQL。 ESQL 是 EF 支持的类似 SQL 的查询语言 - 如果您有兴趣可以阅读更多内容here。由于 EF 对 LINQ 具有良好的支持，因此在很多情况下您会希望使用 ESQL 而不是 Linq to Entities。 Linq to SQL 与 EF/ESQL/Linq to Entities 无关。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
