将.net Func <T>转换为.net Expression <Func <T >>

使用方法调用从lambda到Expression很容易...

public void GimmeExpression(Expression<Func<T>> expression)
{
    ((MemberExpression)expression.Body).Member.Name; // "DoStuff"
}

public void SomewhereElse()
{
    GimmeExpression(() => thing.DoStuff());
}

但是我只想在少数情况下将Func变成表达式...

public void ContainTheDanger(Func<T> dangerousCall)
{
    try 
    {
        dangerousCall();
    }
    catch (Exception e)
    {
        // This next line does not work...
        Expression<Func<T>> DangerousExpression = dangerousCall;
        var nameOfDanger = 
            ((MemberExpression)dangerousCall.Body).Member.Name;
        throw new DangerContainer(
            "Danger manifested while " + nameOfDanger, e);
    }
}

public void SomewhereElse()
{
    ContainTheDanger(() => thing.CrossTheStreams());
}

无效的行给了我编译时错误Cannot implicitly convert type 'System.Func<T>' to 'System.Linq.Expressions.Expression<System.Func<T>>'。显式强制转换不能解决这种情况。有没有我可以忽略的设施？

哦，这根本不容易。Func<T>表示通用delegate而不是表达式。如果有任何方法可以做到（由于优化和编译器完成的其他工作，某些数据可能会被丢弃，因此可能无法取回原始表达式），这将是在即时拆卸IL的过程。并推断表达式（绝非易事）。将lambda表达式视为data（Expression<Func<T>>）是编译器的一项神奇功能（基本上，编译器在代码中构建表达式树，而不是将其编译为IL）。

相关事实

这就是为什么将lambda推到极限的语言（例如Lisp）通常更易于实现为解释器。在这些语言中，代码和数据本质上是同一件事（即使在运行时也是如此），但是我们的芯片无法理解这种形式的代码，因此我们必须通过在可以理解该机器的基础上构建一个解释器来模拟这样的机器（像语言一样由Lisp做出的选择）或在某种程度上牺牲了功能（代码将不再完全等于数据）（C＃做出的选择）。在C＃中，编译器通过允许在编译时将lambda解释为code（Func<T>）和data（Expression<Func<T>>）来给人一种将代码视为数据的错觉。

    private static Expression<Func<T, bool>> FuncToExpression<T>(Func<T, bool> f)  
    {  
        return x => f(x);  
    } 

您可能应该做的就是扭转这种方法。接受一个Expression>，然后编译并运行。如果失败，则已经有表达式需要研究。

public void ContainTheDanger(Expression<Func<T>> dangerousCall)
{
    try 
    {
        dangerousCall().Compile().Invoke();;
    }
    catch (Exception e)
    {
        // This next line does not work...
        var nameOfDanger = 
            ((MemberExpression)dangerousCall.Body).Member.Name;
        throw new DangerContainer(
            "Danger manifested while " + nameOfDanger, e);
    }
}

public void SomewhereElse()
{
    ContainTheDanger(() => thing.CrossTheStreams());
}

显然，您需要考虑这一点对性能的影响，并确定是否确实需要这样做。

您可以通过.Compile（）方法进行另一种选择-不知道这是否对您有用：

public void ContainTheDanger<T>(Expression<Func<T>> dangerousCall)
{
    try
    {
        var expr = dangerousCall.Compile();
        expr.Invoke();
    }
    catch (Exception e)
    {
        Expression<Func<T>> DangerousExpression = dangerousCall;
        var nameOfDanger = ((MethodCallExpression)dangerousCall.Body).Method.Name;
        throw new DangerContainer("Danger manifested while " + nameOfDanger, e);
    }
}

public void SomewhereElse()
{
    var thing = new Thing();
    ContainTheDanger(() => thing.CrossTheStreams());
}

如果有时需要表达式，有时需要委托，则有两个选择：

• 有不同的方法（每一种）
• 始终接受Expression<...>版本，.Compile().Invoke(...)如果您需要委托，则仅接受版本。显然，这是有代价的。

NJection.LambdaConverter是一个将委托转换为表达式的库

public class Program
{
    private static void Main(string[] args) {
       var lambda = Lambda.TransformMethodTo<Func<string, int>>()
                          .From(() => Parse)
                          .ToLambda();            
    }   

    public static int Parse(string value) {
       return int.Parse(value)
    } 
}

 Expression<Func<T>> ToExpression<T>(Func<T> call)
        {
            MethodCallExpression methodCall = call.Target == null
                ? Expression.Call(call.Method)
                : Expression.Call(Expression.Constant(call.Target), call.Method);

            return Expression.Lambda<Func<T>>(methodCall);
        }

塞西尔·莫诺（Cecil Mono）团队的JB伊万（JB Evain）为实现这一目标正在取得一些进展

http://evain.net/blog/articles/2009/04/22/converting-delegates-to-expression-trees

更改

// This next line does not work...
Expression<Func<T>> DangerousExpression = dangerousCall;

至

// This next line works!
Expression<Func<T>> DangerousExpression = () => dangerousCall();