C#表达式中的动态查询-c# =>

当您使用LINQ来处理数据库时，这种体验是一种神奇的体验，对吗?你把数据库实体像一个普通的收集，使用Linq中像Where，Select或者 Take，这些简单的使用就能让代码可用了。

但是，让我们考虑一下这里是如何通过动态查询和表达式树实现此功能的：幕后发生的事情。您编写的LINQ查询将转换为SQL(或其他方式)，并将该SQL查询发送到数据库。然后将数据库的响应映射到C#对象。但是，如何完全转换为SQL?

在本文中，您将看到诸如Entity Framework和MongoDB C#驱动程序之类的框架如何使用表达式树进行转换。您将看到如何亲自使用表达式树来构建动态查询。这些查询是您无法在编译时创建的查询，因为您将知道该查询仅在运行时的外观。

对可查询树和表达式树进行揭秘

考虑以下使用Entity Framework 6的C#代码：

SQL:SELECT 
    [Extent1].[StudentID] AS [StudentID], 
    [Extent1].[StudentName] AS [StudentName], 
    [Extent1].[DateOfBirth] AS [DateOfBirth], 
    FROM [dbo].[Students] AS [Extent1] 
    WHERE N'Billie' = [Extent1].[StudentName]

请注意，WHERESQL查询中有一个操作。那不是很明显。如果SQL不包含WHERE，则所有学生都将从数据库中带走，并且筛选将在.NET进程中执行。实际上，以下代码可以做到这一点：

//BAD: 
DbSet<Student> students = context.Students; 
Func<Student, bool> predicate = s => s.StudentName == "Billie"; 
var x = students.Where(predicate).ToList();

在最后一个示例中，SQL查询使所有学生进入流程，并将其映射到常规集合。不同之处在于，在第一段代码中，lambda是一个Expression

第二段代码在性能，内存和网络方面很糟糕。我们从网络中获取了许多对象，而不是仅从数据库中获取一个项目。然后，我们使用CPU将它们序列化为C#对象。并用完内存将它们存储在进程的堆中。

因此，让我们回到第一段代码。如何await students.Where(s => s.StudentName == "Billie").ToListAsync()产生一个包含的SQL查询WHERE N'Billie' = [Extent1].[StudentName]?

答案是表达树。该代码s => s.StudentName == "Billie"实际上是一个结构化查询，可以通过编程将其分解为节点树。在此示例中，有6个节点。最顶层的节点是lambda表达式。左侧是lambda参数。在它的右边是Equal表示表达式的lambda主体。实体框架具有遍历这些表达式树并构造SQL查询的算法。其他数据源提供程序(如Mongo DB C#驱动程序)也会发生同样的事情，除了它会构造一个MongoDB json查询。

C#表达式树

在第一段代码中，类型s => s.StudentName == "Billie"为Expression

好的，但是我该如何利用它呢?

在大多数情况下，使用表达树的人们就是在构建世界实体框架的人们。但是在某些特定情况下，它变得非常有用。这是我们最近在Ozcode[1](我的日常工作)中遇到的一个用例：

我们想在名为Error的数据库实体上创建动态服务器端过滤。该实体具有许多属性，我们希望允许用户对其进行过滤。因此过滤应根据被允许Username，Country，Version，或任何其他财产。这是我们需要实现的API：

IQueryable<Error> _errors;  
public IEnumerable<Error> GetErrors(string propertyToFilter, string value){ /*..*/}

在这种情况下，propertyToFilter是的属性Error。使用常规的LINQ，唯一的方法就是使用巨大的switch / case语句。有点像这样：

IQueryable<Error> _errors; 
 
public IEnumerable<Error> GetErrors(string propertyToFilter, string value) 
{ 
    switch (propertyToFilter) 
    { 
        case "Username": 
            return await _errors.Where(e=> e.Username == value).ToListAsync(); 
        case "Country": 
            return await _errors.Where(e=> e.Country == value).ToListAsync(); 
        case "Version": 
            return await _errors.Where(e=> e.Version == value).ToListAsync(); 
        // ...         
    } 
}

您可能会同意这不是理想的选择。除了必须编写所有这些东西之外，它还非常容易出现错误。如果添加了属性怎么办?如果重命名怎么办?整个事情一团糟。

通过动态查询和表达式树可以实现此功能的方法如下：

private async static Task<IEnumerable<Error>> GetErrors(string propertyToFilter, string value) 
{ 
    var error = Expression.Parameter(typeof(Error)); 
    var memberAccess = Expression.PropertyOrField(error, propertyToFilter); 
    var exprRight = Expression.Constant(value); 
    var equalExpr = Expression.Equal(memberAccess, exprRight); 
    Expression<Func<Error, bool>> lambda = Expression.Lambda<Func<Error, bool>>(equalExpr, error); 
 
    return await _errors.Where(lambda).ToListAsync(); 
}

这里的每一行代码代表表达式树中的一个节点。它们共同构成了最高节点-lambda。然后，可以在LINQ中使用动态表达式，并生成服务器端SQL查询。我认为很好。

解决此问题的另一种方法是构建自定义SQL查询字符串。在Ozcode中，我们使用的是MongoDB，因此SQL不适合使用，但我们可以创建一个自定义的MongoDB JSON查询字符串。也不是太难，但是我认为表达式树方法更加灵活和可靠。一方面，您可以将其放在LINQ中并与其他LINQ运算符组合。此外，当有诸如Entity Framework之类的经过测试的框架可以为您执行此操作时，为什么还要编写自己的查询。

概要

回顾一下。这是本文中的一些关键点：

常规函数/委托与表达式之间的区别在于，表达式可以用结构化树表示。可以轻松地分析该树以创建诸如数据库查询之类的东西。
支持表达式的数据源实现该IQueryable接口。
如果您无法使用表达式(以及使用常规方法或委托)，则查询将在服务器端而不在数据库端，这对于性能而言将是可怕的。
使用lambda(不带主体)时，表达式是无缝创建的，因此这些年来您可能一直都在这样做。
您可以自己使用表达式树来创建动态查询。这在无法在编译时仅在运行时构建查询的情况下很有用。

References

[1] Ozcode: https://oz-code.com

[2]: https://www.mediavine.com/