Linq表達式用於比較兩個枚舉值

Question

我正在我的應用程序中構建一些表達式，這在大多數情況下都在工作。 但是當我嘗試對枚舉值進行比較操作時，我遇到了麻煩。 例如：

expr = Expression.GreaterThanOrEqual(memberExpression, constExpression);

這樣可以正常工作，直到memberExpression和constExpression的類型為MyEnum ; 這會引發運行時錯誤：

沒有為類型'MyNamespace.MyEnum'和'MyNamespace.MyEnum'定義二元運算符GreaterThanOrEqual。

我可以通過將枚舉值轉換為整數來繞過其他地方，但這似乎是錯誤的，不知何故。 如果我可以在C＃中的MyEnum值之間進行比較操作，那么為什么Expression構建器不允許它呢？

Answer 1

我可以通過將枚舉值轉換為整數來繞過其他地方，但這似乎是錯誤的，不知何故。

它不應該感到錯誤。 畢竟，這就是編譯器本身所做的事情 - 它要么將枚舉值替換為相應的數值（當枚舉值在編譯時已知），要么生成在運行時執行必要強制轉換的代碼。 請注意，這些強制轉換不一定是int ，而是有問題的枚舉的支持類型。

如果我可以在C＃中的MyEnum值之間進行比較操作，那么為什么Expression構建器不允許它呢？

您正在構建的表達式樹看起來與C＃代碼中發生的情況相匹配，但實際上並非如此 - 正是因為編譯器在幕后所做的事情如上所述。

確實沒有技術上的原因， Expression.GreaterThanOrEqual和朋友不能檢查他們的參數並生成與編譯器所做的完全相同的表達式樹。 例如，如果傳入兩個Type等於MyEnum的ConstantExpression ， MyEnum該方法可以使用反射來確定與其參數對應的數值，並且就像傳入該類型的常量表達式而不是拋出一樣。 它也可以處理一般情況（非常數子表達式）。

但是，這樣做意味着表達式樹的WYSIWYG屬性丟失：您會認為您正在生成表達式樹X，而實際上您將生成不同的表達式樹Y.

這可能是完全可取的 - 你當然可以編寫自己的方法來做到這一點 - 但它可能不是一個好主意，因為默認行為（通常C＃的設計避免了DWIM心態），和/或不能證明發展成本。 請記住，有很多地方編譯器可以解除繁重的工作，因此只容納這些場景的一部分是任意的，而容納所有這些場景可能會讓人望而卻步。 看看Roslyn的可用性是否會改變這一評估將會很有趣。

Answer 2

我最終沒有轉換為整數。

private static void Example(string value, Type type, ParameterExpression pe, string propertyName)
{
    Expression whereValue = null;
    if (type.IsEnumOrNullableEnum())
    {
        whereValue = Expression.Constant(Enum.Parse(type, value));
    }
    Expression propExp = Expression.Property(pe, propertyName);
    Expression ruleExpression = Expression.Equal(propExp, whereValue);//results in: item.MyEnum = A
}