问题标签 [linq.compiledquery]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c# - Entity Framework Core 2.2 编译的查询结构参数在本地评估
我一直在研究使用 Entity Framework Core 编译的查询。我正在使用当前最新的稳定版本 2.2.2。我正在阅读这篇文章（https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/ef/language-reference/compiled-queries-linq-to-entities）以了解编译查询，并试图了解这是 EF Core 中的错误还是他们尚未完成的事情。我认识到这篇文章是为 EF6 编写的，但期望编译的查询会以相同的方式工作，并且找不到任何相反的东西。
这是我的 DbContext 设置和一个简单的分页选项结构：
这是我编译的查询。第一个选择基于结构参数的用户“页面”（非常类似于文章中的示例）。第二个做同样的事情，但接受“skip”和“take”作为基本 int32 类型的单独参数。
这是演示问题的用法：
当goodQuery运行时，一切都按预期工作。以下内容在日志中显示为我期望的生成 SQL：
但是，当badQuery运行时，它会选择所有记录，然后评估内存中的 Skip 和 Take，这将导致糟糕的性能。
由于几个非常重要的原因，我更喜欢使用复杂类型（引用或值结构，不关心）作为编译查询的参数：
- Lambda 函数具有最大数量的输入参数。如果我有一个需要多个输入的复杂过滤、排序和分组查询，我将被迫走其他路线。
- 对于调用查询的开发人员来说，输入参数更加清晰。即使在这个例子中，调用查询的开发人员也会开始输入 query.Invoke，然后在智能感知中盯着 2 个未命名的整数参数。他们知道他们的意思的唯一方法是查看查询。如果输入参数更改了顺序或含义，那么对查询的更改将非常危险。
EF Core 3.0 路线图（https://docs.microsoft.com/en-us/ef/core/what-is-new/roadmap）确实表示他们正在研究他们的 LINQ 查询策略（以避免这种可怕的运行查询，或者至少让您在运行前知道或碰巧在您的日志中捕获警告），但我希望 struct 参数能够工作。
如果我做错了什么或者这是正在进行中的事情，有人在这里有任何见解吗？你会认为这也是一个错误吗？