|| （或）使用 C# 的 Linq 中的运算符

Question

我正在使用 linq 筛选消息项的选择。我编写的方法接受一堆可能为空的参数。如果它们为空，则应忽略文件的标准。如果不为null，则使用它来过滤结果。

据我了解，在执行 || 时操作是 C#，如果第一个表达式为真，则不应计算第二个表达式。

例如

if(ExpressionOne() || ExpressionTwo())
{
     // only ExpressionOne was evaluated because it was true
}

现在，在 linq 中，我正在尝试这个：

var messages = (from msg in dc.MessageItems
where  String.IsNullOrEmpty(fromname) || (!String.IsNullOrEmpty(fromname) && msg.FromName.ToLower().Contains(fromname.ToLower()))
select msg);

我会认为这是正确的，因为String.IsNullOrEmpty(fromname) 等于 true 并且 || 的第二部分不会跑。

但它确实会运行，第二部分

msg.FromName.ToLower().Contains(fromname.ToLower()))

抛出空引用异常（因为fromname 为空）！！ - 我得到一个经典的“对象引用未设置为对象的实例”异常。

有什么帮助吗？

Answer 1

阅读 this documentation，它解释了 linq 和 c# 是如何断开连接的。

由于 Linq 表达式预计会简化为普通方法以外的其他内容，因此如果稍后在某些非 Linq to Objects 上下文中使用此代码，您可能会发现此代码会中断。

说的是

String.IsNullOrEmpty(fromname) || 
(   !String.IsNullOrEmpty(fromname) && 
    msg.FromName.ToLower().Contains(fromname.ToLower())
)

结构很糟糕，因为它真的应该是这样的

String.IsNullOrEmpty(fromname) || 
msg.FromName.ToLower().Contains(fromname.ToLower())

这清楚地表明您依赖 msg 和 msg.FromName 两者都不为空。

为了让您在 c# 中的生活更轻松，您可以添加以下字符串扩展方法

public static class ExtensionMethods
{
    public static bool Contains(
        this string self, string value, StringComparison comparison)
    {
        return self.IndexOf(value, comparison) >= 0;
    }

    public static bool ContainsOrNull(
        this string self, string value, StringComparison comparison)
    {
        if (value == null)
            return false;
        return self.IndexOf(value, comparison) >= 0;
    }
}

然后使用：

var messages = (from msg in dc.MessageItems
where  msg.FromName.ContainsOrNull(
    fromname, StringComparison.InvariantCultureIgnoreCase)
select msg);

但这不是问题所在。问题是系统的 Linq to SQL 方面正在尝试使用fromname 值来构造发送到服务器的查询。

由于fromname 是一个变量，因此翻译机制会关闭并执行所要求的操作（即使fromname 为空，也会生成小写表示，这会触发异常）。

在这种情况下，您可以执行您已经发现的操作：保持查询不变，但确保始终可以创建具有所需行为的非 null fromname 值，即使它为 null。

或许更好：

IEnumerable<MessageItem> results;
if (string.IsNullOrEmpty(fromname))
{ 
    results = from msg in dc.MessageItems 
    select msg;    
}
else
{
    results = from msg in dc.MessageItems 
    where msg.FromName.ToLower().Contains(fromname) 
    select msg;    
}

这不是很好，因为查询包含其他约束，因此涉及更多重复，但对于简单查询实际上应该导致更多可读/可维护的代码。如果您依赖匿名类型，这会很痛苦，但希望这对您来说不是问题。

Answer 2

好的。我找到了一个解决方案。

我将违规行改为：

where (String.IsNullOrEmpty(fromemail)  || (msg.FromEmail.ToLower().Contains((fromemail ?? String.Empty).ToLower())))

它有效，但感觉就像一个黑客。我确定第一个表达式是否为真，第二个表达式不应该被评估。

如果有人可以为我确认或否认这一点，那就太好了...

或者如果有人有更好的解决方案，请告诉我！！！

Answer 3

如果您使用的是 LINQ to SQL，您不能在 SQL Server 中期望相同的 C# 短路行为。请参阅this question，了解 SQL Server 中的短路 WHERE 子句（或缺少子句）。

另外，正如我在评论中提到的，我认为您不会在 LINQ to SQL 中遇到此异常，因为：

1. 方法 String.IsNullOrEmpty(String) 不支持 SQL 转换，因此您不能在 LINQ to SQL 中使用它。
2. 您不会得到 NullReferenceException。这是一个托管异常，它只会发生在客户端，不会发生在 SQL Server 中。

你确定这不是在某个地方通过 LINQ to Objects 吗？您是在源上调用 ToList() 或 ToArray() 还是在运行此查询之前将其引用为 IEnumerable？

---

更新：在阅读了您的 cmets 之后，我再次对此进行了测试并意识到了一些事情。我错了你不使用 LINQ to SQL。您没有收到 "String.IsNullOrEmpty(String) has no supported translation to SQL" 异常，因为 IsNullOrEmpty() 是在局部变量上调用的，而不是 SQL 列，因此它在客户端运行，即使您使用的是 LINQ to SQL (不是 LINQ to Objects）。由于它在客户端运行，您可以在该方法调用上获得NullReferenceException，因为它没有被转换为SQL，您无法获得NullReferenceException。

让您的解决方案看起来不那么老套的一种方法是在查询之外解决 fromname 的“null-ness”：

string lowerfromname = String.IsNullOrEmpty(fromname) ? fromname : fromname.ToLower();

var messages = from msg in dc.MessageItems
               where String.IsNullOrEmpty(lowerfromname) || msg.Name.ToLower().Contains(lowerfromname)
               select msg.Name;

请注意，这并不总是被翻译成类似（以您的 cmets 为例）：

SELECT ... FROM ... WHERE @theValue IS NULL OR @theValue = theValue

它的翻译将在运行时根据fromname 是否为空来决定。如果它为空，它将在没有WHERE 子句的情况下进行翻译。如果它不为空，它将使用简单的“WHERE @theValue = theValue”进行翻译，而不会在 T-SQL 中进行空检查。

所以最后，在这种情况下，它是否会在 SQL 中短路的问题是无关紧要的，因为如果fromname 为空，LINQ to SQL 运行时将发出不同的 T-SQL 查询。从某种意义上说，就是在查询数据库之前把客户端短路了。

Answer 4

您确定是 'fromname' 为空，而不是 'msg.FromName' 为空吗？

Answer 5

就像布赖恩说的，我会在执行 ToLower().Contains(fromname.ToLower())) 之前查看 msg.FromName 是否为空

Answer 6

您是正确的，因为您使用的是短路比较器（请参阅What is the best practice concerning C# short-circuit evaluation?），因此不应评估第二个条件，但是我怀疑 Linq 可能会在执行之前尝试优化您的查询并在这样做可能会改变执行顺序。

对我来说，将整个内容括在括号中也可以更清楚地说明，因为整个“where”条件都包含在括号中。