读EntityFramework.DynamicFilters源码_心得_设计思想_04

时间:2023-12-23 15:45:50

前几次,我们从说明文档,示例,单元测试了解了怎么用这个动态过滤器,那么如果仅仅是为了实现目的,知道怎么用就可以完成相应的功能开发,但我还想了解的问题是

  1. 作者是怎么将动态过滤器与EF结合的
  2. 有哪些设计思想在里面
  3. 为什么这样设计
  4. 这个设计是最好的么,其他框架是怎么做的
  5. 这样做有什么优点和缺点
  6. 我可以从里面学习到什么思想和技术

    首先,让我们抛开这个小扩展,回到ado.net时代,假如数据库里面有如下几个表:

读EntityFramework.DynamicFilters源码_心得_设计思想_04

我想实现假删除功能,删除People表里面id=11的

update people set IsDeleted=1 where ID=11

读EntityFramework.DynamicFilters源码_心得_设计思想_04

删除完之后,查询没有被删除的数据

正常情况下,那个假删除的数据对于用户来说就是真删除,只是库里面还有

如果是调用者最终控制查询语句,那他要手动过滤掉假删除的数据数据

select * from People where IsDeleted!=1

读EntityFramework.DynamicFilters源码_心得_设计思想_04

那用户写语句的时候,不会去考虑你这个数据是不是假删除的,对于他来说,就是没有

这个时候,他只需要写select * from People 就应该查询出来

读EntityFramework.DynamicFilters源码_心得_设计思想_04

可实际上 ,查询出来的是

读EntityFramework.DynamicFilters源码_心得_设计思想_04

查询的时候,自然不能查询出来已经删除的数据,应该过滤掉

用户去做这件事的时候,每个语句都要处理手动加上过滤条件,当用户站到业务层去实现业务的时候,他还要考滤数据层的问题,怎么将用户的业务与数据层的关联给解耦

用户不去做这件,又要实现这样的功能,就是用户在业务层发出了查询

select * from People 的命令 然后系统自动查询出来如下正确的结果

读EntityFramework.DynamicFilters源码_心得_设计思想_04

那就需要系统去动态处理,将原来的select * from People 转换成

select * from People where IsDeleted!=1 加上过滤假删除的条件

这只是动态过滤场景里面的一种场景,如果系统里面只是有一个这样的,我们手动也可以很快搞定。当系统里面有很多类似但不同的场景,比如saas多租户,我想查询出来系统里面

当前登录租户的所有数据,但是对于登录者来说并没有租户的概念,这个系统好像就他自己在用 这个时候,我们也在针对不同的场景去做设置,那么要是有100种不同场景,1000种

是不是我们都去一个个的去做呢?

他里面是不是有相似可以提取的,如果老板突然哪天说系统不要用假删除了,太占数据库空间,那原来做的设置要怎么快速的去掉呢?

用户面向的都是对象,就算让用户设置也不能让用户去写一大推的sql语句吧,那要是数据库不切换还好,要是sql换oracle 再换成mysql 是不是每次都要改语句呢,每次改的内容是不是差别不大,相似不小,不改又运行不了?

怎么解决这些一系列问题,EntityFramework.DynamicFilters 源码里面都给出了自己的答案

要解决的问题,如过滤器要

  1. 动态可插拔
  2. 跨数据库
  3. 满足用户的不同场景
  4. 容易扩展,实现定制化开发
  5. ……

EntityFramework.DynamicFilters.通过DynamicFilterExtensions 提供对外的过滤器构建方法,方法都是通过对象扩展到EF框架里面的DbModelBuilder modelBuilder 对象上,

调用的时候,通过扩展方法,可以方便的实现过滤器的禁用,启用,创建

读EntityFramework.DynamicFilters源码_心得_设计思想_04

支持各种场景,具体的使用方式参考单元测试

动态禁用和启用

modelBuilder.DisableFilterGlobally("BlogEntryFilter")禁用过滤器

modelBuilder.EnableFilter(dbContext,filterName);启用过滤器

过滤器 modelBuilder.Filter("IsDeleted", (ISoftDelete d) => d.IsDeleted, false);

通过LambdaToDbExpressionVisitor 将定义过滤器传过来的表达式((ISoftDelete d) => d.IsDeleted, false)转换成数据库表达式

通过命令截断器,拦截将要执行到数据库的语句,加上由用户创建的过滤器,由LambdaToDbExpressionVisitor转换过来的DbExpression,形成最终的语句,对于用户来说屏蔽掉自己手动添加语句的细节

对于不满足我们的要求的可以扩展System.Data.Entity.Infrastructure.Interception

//

// 摘要:

//     An object that implements this interface can be registered with System.Data.Entity.Infrastructure.Interception.DbInterception

//     to receive notifications when Entity Framework executes commands.

//

// 备注:

//     Interceptors can also be registered in the config file of the application. See

//     http://go.microsoft.com/fwlink/?LinkId=260883 for more information about Entity

//     Framework configuration.

public interface IDbCommandInterceptor : IdbInterceptor

命令截断器接口,实现自己的拦截方式

然后在InitializeDynamicFilters(this DbContext context)

读EntityFramework.DynamicFilters源码_心得_设计思想_04

调用拦截器集合,自己的拦截器加入进去就可以实现自己的定制化

读EntityFramework.DynamicFilters源码_心得_设计思想_04

Rafy 框架假删除插件也是通过拦截器实现的如下:

读EntityFramework.DynamicFilters源码_心得_设计思想_04

StampSubmitInterceptor 实现抽象拦截器SubmitInterceptor

读EntityFramework.DynamicFilters源码_心得_设计思想_04

在插件初始化的时候,将自定义插件添加到集合里面

当前拦截器,执行完之后,调用下一个拦截器

link.InvokeNext(this, e);

通过rafy的删除插件,与EntityFramework.DynamicFilters 过滤器的对比都是通过命令截断器实现

Rafy的命令截断器是作者自定义的SubmitInterceptor

EntityFramework.DynamicFilters实现的是EF自己的IdbCommandInterceptor