是否有人知道在编译时未捕获的LINQ to SQL查询限制的权威列表,以及(如果可能)该限制的解决方法?
到目前为止,我们的列表是:
.Date
DateTime
string.IsNullOrEmpty
== ""
.Last()
.OrderByDescending(x => x.WhateverProperty).First()
基本上,该名单是巨大的…它是相对的外面的一切小那套东西 被 处理。不幸的是,泄漏抽象定律开始了,每个提供者都有不同的答案…
LINQ-to-Objects将做任何事情(几乎),因为它是委托。LINQ-to-SQL和实体框架具有 不同 的支持集。
通常,使用DateTime属性等取得了相当大的成功- 但实际上,您将必须确保查询表达式包含在单元测试中,以便在您更改提供者(或提供者)的情况下进行更新),您知道这一切仍然有效。
我想有一种观点是根据TSQL来考虑的。没有BOTTOM n,但是有一个TOP 1(re OrderByDescending);在方面string.IsNullOrEmpty,你可能是相当字面:foo.Bar == null || foo.Bar == ""; 并且DateTime.Date您可能可以使用DATEPART/各种组件做很多事情。
BOTTOM n
TOP 1
OrderByDescending
foo.Bar == null || foo.Bar == ""
DateTime.Date
DATEPART
LINQ-to-SQL的另一种选择是将逻辑封装在UDF中-因此您可以编写一个UDF,该UDF接受adatetime并返回a datetime,并通过dbml将其公开到数据上下文中。然后,您可以在查询中使用它:
datetime
where ctx.Date(foo.SomeDate) == DateTime.Today
但是,这种方法不一定能很好地利用索引。
更新:
有关完整的细节,您可以查看System.Data.Linq.SqlClient.PostBindDotNetConverter+Visitor反射器- 特别是Translate...方法;有些string功能是分开处理的。因此,这不是一个 巨大的 选择-但这是一个实现细节。
System.Data.Linq.SqlClient.PostBindDotNetConverter+Visitor
Translate...
string