Entity Framework Core 2.0引入了全局查询过滤器，可以在创建模型时应用到实体 。它使得构建多租户应用程序和支持对实体 的软删除变得更加容易。这篇博客文章提供了关于如何在实际应用中使用全局查询过滤器的更深入的概述，以及如何将全局查询过滤器自动应用到领域实体。
示例解决方案。我在Core 2中构建了示例解决方案EFCoreGlobalQueryFilters在更复杂的上下文中演示了全局查询过滤器。它演示了如何自动地将全局查询过滤器应用到领域实体。创建简单的数据库并使用sql脚本填充测试数据。
这就是全局查询筛选器在软删除时的样子。我们在DbContext类中重写了OnModelCreating方法。
上面的代码是简化的，不考虑实际的应用场景。但是应用程序的体系结构通常是复杂的。所以当我们考虑到作为数字核心或企业一部分任务的关键的应用程序时，创建的将不仅仅是几个类。本文的目标是演示以下内容:
示例解决方案有助于我们从更复杂的场景开始，但它没有提供完全灵活和复杂的框架。当涉及到现实生活中的应用程序时，涉及的问题太多了，而每个应用程序通常都有自己的解决方案，以解决不同的问题。
让我们从定义一些实体开始。他们使用简单的基类，并且期望所有的实体都从基类扩展。
现在我们有一些简单的实体了，是时候对多租户和软删除的实体进行下一步操作了。
在讨论多租户之前，web应用程序必须有某种方式来检测与当前请求相关的租户。它可以是基于host的header检测，但也可以是别的东西。在这篇文章中我们使用虚拟的提供者以便于我们提供简单的示例。
我希望在这一点上,已经创建了这个数据库，并配置了应用程序来使用它，好了现在让我们从支持租户提供程序的简单数据上下文开始
现在我们有了可操作的context和租户ID，那么接下来我们就可以对自动创建的全局查询过滤器进行下一步操作了。
在为所有实体类型添加全局查询过滤器之前，必须检测实体类型。如果我们知道基本实体类型，那么就很容易读取这些类型。但是有一个问题-model是建立在每个请求之上的，而我们每次在创建model时都要扫描程序集，显然这并不是一个好主意。因此，类型检测必须支持某种类型的缓存。下面示例中的这两个方法用于数据上下文类。
警告!如果有单独的服务来返回实体类型，那么在体系结构方面可以更好地理解。在上面的代码中，可以直接使用实体类型变量，而更糟糕的是，可以调用GetReferencingAssemblies方法。如果您编写真正的应用程序，那么最好使用单独的提供程序。
现在，数据上下文知道实体类型，并且可以编写一些代码来获得适用于所有实体的查询过滤器。
这听起来很容易做，但事实并非如此。有些实体类型的列表，并没有直接使用方便的通用方法。在这一点上，需要一个小技巧。我从CodeDump页面找到了解决方案EF-Core 2.0 过滤所有查询 (并试图实现软删除). 这里的代码不能使用，因为这里的数据上下文对ITenantProvider有实例级的依赖关系。但要点仍然是相同的:让我们为数据上下文中的一些通用方法创建通用方法调用。
这不是一种简单直观的代码。甚至当我看着这段代码时，我也会瞪大眼睛。即使我看了上百遍，它仍然看起来很疯狂和笨拙。SetGlobalQuery方法也是为实体定义主键的好地方，因为它们都是从相同的基础实体类继承而来的。
如果我们想要了解全局查询过滤器是如何工作的，我们可以使用样例应用程序中的HomeController 来实现这一点。
Web应用程序现在可以运行了。下面是我使用的示例数据。让我们记住，示例应用程序使用的租户ID是069b57ab-6ec7-479c-b6d4-a61ba3001c86。
当我们比较这两个表时，我们会很容易发现全局查询过滤器在工作中给出的预期结果。
全局查询过滤器是Entity Framework Core 2.0的完美补充，如果没有很多实体，那么我们可以通过文档中给出的简单示例来实现。在更复杂的情况下，需要一些复杂的代码来自动应用全局查询过滤器。希望将来会有更好的解决方案，但目前这里给出的解决方案也做得很好。