前言
EntityFramework Core每一次版本的迭代和更新都会带给我们惊喜,每次都会尽量满足大部分使用者的需求。在EF Core 2.0版本中出现了全局过滤新特性即HasQueryFilter,它出现的意义在哪里?能够解决什么问题呢?这是我们需要思考的问题。通过HasQueryFilter方法来创建过滤器能够允许我们对访问特定数据库表的所有查询额外添加一模一样的过滤器。它主要用于软删除(soft-delete)场景,即用户并不想返回那些被标记为已删除但是尚未从数据库中做物理删除的数据行。
HasQueryFilter全局过滤器
在文章开头我们讲述了HasQueryFilter特性所解决的问题,下面我们利用实际例子来讲述一下。在许多场景中我们并不会从物理上删除数据,而只是仅仅改变数据的状态。这个时候就凸显了HasQueryFilter特性的作用。比如我们创建一个博客实体。
是不是因为我们本节讲述全局过滤所以才会加IsDeleted字段呢?显然不是,这个是有其应用场景,当我们管理自己的博客时,可能瞌睡没睡好(当然也有其他原因,不必纠结于此)导致一个不小心删除了某一篇文章即使在博客后台有友好提示【是否删除该博客】,但是你依然手滑删除了,这个时候我们找到博客园运营反应,然后分分钟就还原了我们所删除的博客,就像将文件扔到了回收站再还原一样。接下来我们在OnModelCreating方法或者单独建立的映射类中配置过滤未被删除的博客,如下:
要是我们对于特殊场景需要禁用查询过滤或者说忽略查询过滤又该如何呢?通过对应的APi(IgnoreQueryFilters)即可,如下:
使用HasQueryFilter进行查询过滤是不是就是如此简单呢?是不是问题到此就这样结束了呢?看过Jeff博客的童鞋知道,Jeff经常问这样的问题且自问自答,肯定不止于此,我们继续往下探索。上述我们只是应用一个博客实体,我们还存在发表实体且二者存在关联关系,我们同上在Post中定义IsDeleted字段,此时我们在对Blog进行过滤的同时也对Post进行过滤,如下:
builder.HasQueryFilter(f => !f.IsDeleted && f.Posts.All(w => !w.IsDeleted));
由上得知使用HasQueryFilter进行过滤筛选的局限性之一。
局限性一:HasQueryFilter方法过滤筛选无法应用于导航属性。
接下来我们再来看一个例子,首先我们定义如下继承关系:
上述我们定义支付基类Payment,然后派生出现金支付CashPayment和信用卡支付CreditcardPayment子类,接下来我们配置如下查询过滤:
builder.HasQueryFilter(f => !(f is CreditcardPayment && f.IsDeleted && ((CreditcardPayment)f).IsDeleted));
接下来我们进行如下查询:
using (var context = new EFCoreDbContext()) { var payments = context.Payments.ToList(); }
没毛病,接下来我们查询子类CreditcardPayment,如下:
using (var context = new EFCoreDbContext()) { var payments = context.Payments.OfType<CashPayment>().ToList(); }
由上得知使用HasQueryFilter进行过滤筛选的局限性之二。
局限性二:HasQueryFilter方法过滤筛选只能定义在基类中,无法对子类进行过滤。
HasQueryFilter通用解决方案
不知我们是否思考过一个问题,若有很多实体都有其软删除场景,那么我们就都需要加上IsDeleted字段,同时还需要配置全局过滤器,如此重复性动作我们是否觉得厌烦,搬砖的我们的单从程序角度来看,搬砖的本源就是为了解放劳动生产率,提高工作效率,说的更通俗一点则是解决重复性劳动。此时为了解决上述所延伸出的问题,我们完全可抽象出一个软删除接口,如下:
public interface ISoftDleteBaseEntity { bool IsDeleted { get; set; } }
接下来让所有需要进行软删除的实体继承该接口,比如博客实体,如下:
为了解决重复性配置劳动,我们让所有继承自上述接口一次性在OnModelCreating方法中配置全局过滤,如此一来则免去了在每个对应实体映射类中进行配置,如下:
愿望是美好的,结果尼玛抛出异常不支持该操作。看到上述lambda表达式都没有翻译过来,此时我们转到定义看看。
public virtual EntityTypeBuilder HasQueryFilter([CanBeNullAttribute] LambdaExpression filter);
居然参数类型不是以表达式树的形式给出,如果是如下形式则肯定可以。
public virtual EntityTypeBuilder HasQueryFilter([CanBeNullAttribute] Expression<Func<TEntity, TProperty>> filter);
所以问题出在无法翻译lambda表达式,那么我们就来自动构建lambda表达式参数和主体,如下:
至此美好愿望得意实现,算是给出了一种通用解决方案。
总结
本节我们讲述了EntityFramework Core 2.0中的新特性HasQueryFilter,使用此特性仍然存在局限性无法对导航属性属性进行过滤,对实体为继承次模型,那么过滤筛选只能定义在基类中,但是最后我们给出了通用解决方案解决重复定义查询过滤问题,希望给阅读的您一点帮助。精简的内容,简单的讲解,希望对阅读的您有所帮助,我们明天再会。