Question

我已经在ASP.NET 3.0世界中生活了很长时间。我最近接触过从3.0版开始的所有很酷的东西。我想我现在已经很好地掌握了匿名函数和代理，但是这个表达树的东西只是让我大吃一惊。我的第一个倾向是“为什么我需要创建这样复杂的代码”。只是看着它让我感到愚蠢，我已经编写了超过25年的代码。以下是我希望有人可以为我清楚解释的一些代码。

ParameterExpression param = Expression.Parameter(typeof (Product), "product");

Func<Product, object> func = Expression.Lambda<
    Func<Product, object>>(
    Expression.Convert(
        Expression.Property(param, typeof (Product).GetProperty(sidx)), typeof (object)
        ), param).Compile();


IEnumerable<Product> products = null;
switch (sord)
{
    case "asc":
        products = _productRepository.GetTop100Products().OrderBy(func)
            .Skip(pageIndex*pageSize).Take(pageSize).AsEnumerable();
        break;
    case "desc":
        products = _productRepository.GetTop100Products().OrderByDescending(func)
            .Skip(pageIndex*pageSize).Take(pageSize).AsEnumerable();
        break;
    default:
        break;
}

这是一些从AdventureWorks数据库查询产品的代码。有人可以向我解释为什么所有这些Expression.Lamba的东西都是必要的吗？有没有其他方法可以做任何正在发生的事情？

Answer 1

只有在需要选择要按字符串排序的属性时，才需要执行此操作。如果您不需要，可以使用lambda：

对排序表达式进行硬编码

Func<Product, object> func = product => product.sidx;

或者您可以将其作为您的功能参数。

但是如果你真的想要使用LINQ作为字符串给出的属性进行排序，那么这可能是最好的选择。如果你经常做类似的事情，你当然可以隐藏一个辅助方法背后的所有这些，这可以显着简化代码。

此外，如果您尝试使用LINQ to SQL或类似的东西，那么您的代码是错误的。 Func<Product, object>无法转换为SQL，只有Expression<Func<Product, object>>可以。这意味着您应该从代码中移除对Compile()的调用。

表达树混乱

1 个答案: