读EntityFramework.DynamicFilters源码_心得_设计思想_04
前几次，我们从说明文档，示例，单元测试了解了怎么用这个动态过滤器，那么如果仅仅是为了实现目的，知道怎么用就可以完成相应的功能开发，但我还想了解的问题是
- 作者是怎么将动态过滤器与EF结合的
- 有哪些设计思想在里面
- 为什么这样设计
- 这个设计是最好的么，其他框架是怎么做的
- 这样做有什么优点和缺点
- 我可以从里面学习到什么思想和技术
首先，让我们抛开这个小扩展，回到ado.net时代，假如数据库里面有如下几个表：
我想实现假删除功能，删除People表里面id=11的
update people set IsDeleted=1 where ID=11
删除完之后，查询没有被删除的数据
正常情况下，那个假删除的数据对于用户来说就是真删除，只是库里面还有
如果是调用者最终控制查询语句，那他要手动过滤掉假删除的数据数据
select * from People where IsDeleted!=1
那用户写语句的时候，不会去考虑你这个数据是不是假删除的，对于他来说，就是没有
这个时候，他只需要写select * from People 就应该查询出来
可实际上 ，查询出来的是
查询的时候，自然不能查询出来已经删除的数据，应该过滤掉
用户去做这件事的时候，每个语句都要处理手动加上过滤条件，当用户站到业务层去实现业务的时候，他还要考滤数据层的问题，怎么将用户的业务与数据层的关联给解耦
用户不去做这件，又要实现这样的功能，就是用户在业务层发出了查询
select * from People 的命令 然后系统自动查询出来如下正确的结果
那就需要系统去动态处理，将原来的select * from People 转换成
select * from People where IsDeleted!=1 加上过滤假删除的条件
这只是动态过滤场景里面的一种场景，如果系统里面只是有一个这样的，我们手动也可以很快搞定。当系统里面有很多类似但不同的场景，比如saas多租户，我想查询出来系统里面
当前登录租户的所有数据，但是对于登录者来说并没有租户的概念，这个系统好像就他自己在用 这个时候，我们也在针对不同的场景去做设置，那么要是有100种不同场景，1000种
是不是我们都去一个个的去做呢？
他里面是不是有相似可以提取的，如果老板突然哪天说系统不要用假删除了，太占数据库空间，那原来做的设置要怎么快速的去掉呢？
用户面向的都是对象，就算让用户设置也不能让用户去写一大推的sql语句吧，那要是数据库不切换还好，要是sql换oracle 再换成mysql 是不是每次都要改语句呢，每次改的内容是不是差别不大，相似不小，不改又运行不了？
怎么解决这些一系列问题，EntityFramework.DynamicFilters 源码里面都给出了自己的答案
要解决的问题，如过滤器要
- 动态可插拔
- 跨数据库
- 满足用户的不同场景
- 容易扩展，实现定制化开发
- ……
EntityFramework.DynamicFilters.通过DynamicFilterExtensions 提供对外的过滤器构建方法，方法都是通过对象扩展到EF框架里面的DbModelBuilder modelBuilder 对象上，
调用的时候，通过扩展方法，可以方便的实现过滤器的禁用，启用，创建
支持各种场景，具体的使用方式参考单元测试
动态禁用和启用
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)
调用拦截器集合，自己的拦截器加入进去就可以实现自己的定制化
Rafy 框架假删除插件也是通过拦截器实现的如下：
StampSubmitInterceptor 实现抽象拦截器SubmitInterceptor
在插件初始化的时候，将自定义插件添加到集合里面
当前拦截器，执行完之后，调用下一个拦截器
link.InvokeNext(this, e);
通过rafy的删除插件，与EntityFramework.DynamicFilters 过滤器的对比都是通过命令截断器实现
Rafy的命令截断器是作者自定义的SubmitInterceptor
EntityFramework.DynamicFilters实现的是EF自己的IdbCommandInterceptor
