C#表达式中的动态查询详解【译】

前言

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

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

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

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

考虑以下使用entity framework 6的c＃代码：

dbset<student> students = context.students;
var billie = await students.where(s => s.studentname == "billie").tolistasync();

执行时，实体框架会产生以下sql查询：

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<func<student, bool>>，它允许实体框架将其添加到sql查询中。在第二段代码中，lambda是a func<student, bool>，因此将where执行操作符之前的所有操作并将其转换为常规ienumerable集合，然后执行其余的查询。

第二段代码在性能，内存和网络方面很糟糕。我们从网络中获取了许多对象，而不是仅从数据库中获取一个项目。然后，我们使用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<func<student, bool>>。这表示生成树的表达式树func<student, bool>。该where子句接受这种类型的参数，因为adbset<tentity>实现了iqueryable<t>接口，这要求它与表达式树配合使用。相反，常规集合（如数组或a list<t>）ienumerable意味着它将lambdas => s.studentname == "billie"用作常规函数。

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

在大多数情况下，使用表达树的人们就是在构建世界实体框架的人们。但是在某些特定情况下，它变得非常有用。这是我们最近在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（不带主体）时，表达式是无缝创建的，因此这些年来您可能一直都在这样做。

•您可以自己使用表达式树来创建动态查询。这在无法在编译时仅在运行时构建查询的情况下很有用。

总结

到此这篇关于c#表达式中的动态查询的文章就介绍到这了,更多相关c#表达式的动态查询内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！

references

[1] ozcode:

[2]: