为什么普通法则在评估布尔表达式时不适合LINQ？

Question

在这样的码：

if (insuranceNumberSearch == null 
    ? true 
    : ei.InsuranceNumber.Contains(insuranceNumberSearch.Trim())) 
    doSomething(); 

其中insuranceNumberSearch为空时，剩余的表达不为空，而在下面的代码：

var q = from ei in session.Linq<EmployeeInsurance>() 
     where insuranceNumberSearch == null 
       ? true 
       : ei.InsuranceNumber.Contains(insuranceNumberSearch.Trim()) 
     select ei; 

不管表达的所有部分被评估insuranceNumberSearch的是null，或者不是空值。

我使用LINQ to NHibernate的

UPDATE：

不幸的是我已经把第一个片段是错误的。正确的是：

if (insuranceNumberSearch == null || (insuranceNumberSearch != null && ei.InsuranceNumber.Contains(insuranceNumberSearch.Trim())) 
doSomething(); 

或

bool b1 = insuranceNumberSearch == null ? true : ei.InsuranceNumber.Contains(insuranceNumberSearch.Trim()); 
if (b1) 
doSomething(); 

在两种以上时insuranceNumberSearch是null，剩余表达式不评估任何更多。如果这种行为不存在，insuranceNumberSearch.Trim()将导致引用对象为空异常。可悲的是，LINQ（或者LINQ到NHibernate）不服从这样一个好的行为，并且即使在insuranceNumberSearch是null并且导致错误时也评估所有表达式。

更新2：我发现了一个类似的问题：The || (or) Operator in Linq with C#

Answer 1

打我，但问心无愧就不会使用

if (
    (insuranceNumberSearch == null) || 
    ei.InsuranceNumber.Contains(insuranceNumberSearch.Trim())) 
    doSomething(); 

在你的说法，无论是在LINQ表达或不？

Answer 2

正如这段代码所证明的，这不是LINQ的问题。此代码与你相似，但它并没有在LINQ表达式计算该条件的两面：

class Program 
{ 
    class MyClass 
    { 
    public string value; 
    public MyClass(string value) { this.value = value; } 
    public bool Contains(char elem) 
    { 
     Console.WriteLine("Checking if {0} contains {1}", value, elem); 
     return value.Contains(elem); 
    } 
    } 

    static void Main(string[] args) 
    { 
    var mc = new MyClass[2]; 
    mc[0] = new MyClass("One"); 
    mc[1] = new MyClass(null); 
    var q = from i in mc where i.value == null ? true : i.Contains('O') select i; 
    foreach (MyClass c in q) 
     Console.WriteLine(c.value == null ? "null" : c.value); 
    } 
} 

这是可能的表达式求值的LINQ NHibernate的不执行shotcut条件操作的LINQ方式对象呢。

的程序的输出是：

Checking if One contains O 
One 
null 

记住LINQ是表示用于转换成其他语法任意表达式的方法。据我了解，LINQ本身不会评估表达式，NHibernate会（不管那是什么）。所以LINQ只是将你提供的表达式转换成与NHibernate兼容的表达式。如果NHibernate的不具有较快捷的条件操作的手段，我能想象的3件事情之一发生：

1. NHibernate的将评估表达自己的方式（就像LINQ to SQL中永远的快捷方式，即使操作你使用VB.NET中的非快捷AND运算符）。
2. 你会得到一个错误，表达式不能用NHibernate语法表示。
3. 只有一部分查询将被转换为NHibernate语法;其余的将由LINQ to Objects评估。

Answer 3

看来问题出在LINQ的NHibernate提供程序上 - 对于LINQ来说，对象（只对查询执行简单的句法转换来进行方法调用），这个法则会按照预期保持。问题是，当与表达式树一起工作时，提供者可以对您的代码进行任何修改。

甚至可能更糟 - 目标执行环境可能不支持某些C＃操作的确切语义。例如，它可能没有相同的浮点运算实现。

在你的例子中，似乎NHibernate不支持短路行为。我不清楚为什么这会是一个问题 - 它可以评估表达的第二部分，但结果应该是相同的。

无论如何，如果短路导致运营商对问题的供应商，你可能需要将查询拆分为两个：

var q = 
    insuranceNumberSearch == null 
    ? session.Linq<EmployeeInsurance>() 
    : (from ei in session.Linq<EmployeeInsurance>() 
     where ei.InsuranceNumber.Contains(insuranceNumberSearch.Trim()) 
     select ei);