上一篇《更加简练的编程体验》提供了最新版本的Dora.Interception代码的AOP编程体验，接下来我们会这AOP框架的编程模式进行详细介绍，本篇文章着重关注的是拦截器的定义。采用“基于约定”的Interceptor定义方式是Dora.Interception区别于其他AOP框架的一个显著特征，要了解拦截器的编程约定，就得先来了解一下Dora.Interception中针对方法调用的拦截是如何实现的。
一、针对实例的拦截
总地来说，Dora.Interception针对方法调用的拦截机制分为两种类型，我将它称为“针对实例的拦截”和“针对类型”的拦截。针对实例的拦截应用于针对接口的方法调用，其原理如下所示：类型Foobar实现了接口IFoobar，如果需要拦截以接口的方式调用Foobar对象的某个方法，我们可以动态生成另一个用来封装Foobar对象的FoobarProxy类型，FoobarProxy同样实现IFoobar接口，我们在实现的方法中实现对Interceptor链的调用。我们最终将原始提供的Foobar对象封装成FoobarProxy对象，那么针对Foobar的方法调用将转换成针对FoobarProxy对象的调用，拦截得以实现。
二、针对类型的拦截
如果Foobar并未实现任何接口，或者针对它的调用并非以接口的方式进行，那么我们只能采用“针对类型的拦截”，其原理如下：我们动态创建Foobar的派生类型FoobarProxy，并重写其需要被拦截的虚方法来实现对Interceptor链的调用。我们最终创建FoobarProxy对象来替换掉原始的Foobar对象，那么针对Foobar的方法调用将转换成针对FoobarProxy对象的调用，拦截得以实现。
由于这种拦截方式会直接创建代理对象，无法实现针对目标对象的封装，当我们进行DI服务注册的时候，只能指定注册服务的实现类型，不能指定一个现有的Singleton实例或者提供一个创建实例的Factory。
三、从两个Delegate说起
要理解Dora.Interception的设计，先得从如下这两个特殊的Delegate类型（InterceptDelegate和InterceptorDelegate）说起。InterceptDelegate代表针对方法的拦截操作，作为输入参数的InvocationContext提供了当前方法调用的所有上下文信息，返回类型被设置为Task意味着Dora.Interception提供了针对基于Task的异步编程的支持。
public delegate Task InterceptDelegate(InvocationContext context);public delegate InterceptDelegate InterceptorDelegate(InterceptDelegate next);public abstract class InvocationContext
{ public abstract object[] Arguments { get; } public abstract MethodBase Method { get; } public InterceptDelegate Next { get; } public abstract object Proxy { get; } public abstract object ReturnValue { get; set; } public abstract object Target { get; } public MethodBase TargetMethod { get; } public abstract IDictionary<string, object> ExtendedProperties { get; } public Task ProceedAsync();
}InterceptDelegate表示的是“拦截操作”，即表示作用于InvocationContext上下文上的一个Task，但它并不能表示一个拦截器对象。原因很简单，因为注册到同一个方法上的多个拦截器对象会构成一个链条，最终决定是否调用后一个拦截器或者目标方法（对于链条尾部的Interceptor）是由当前拦截器决定的，所以如果将Interceptor也表示成委托对象，它的输入应该是一个InterceptDelegate对象，表示针对后一个拦截器或者目标方法的调用，它返回的同样也是一个InterceptDelegate对象，表示将自身纳入拦截器链之后，新的拦截器链条（包括调用目标方法）所执行的操作。
所以一个Interceptor在Dora.Interception中应该表示成一个Func<InterceptDelegate, InterceptDelegate>对象，这与ASP.NET Core的中间件管道其实是一回事。简单起见，我们为它专门定义了一个委托类型InterceptorDelegate。
四、将一个对象转换成Interceptor
虽然Dora.Interception总是将Interceptor对象表示成上面介绍的InterceptorDelegate类型的委托，但是为了更好的编程体验，我们可以选择采用POCO类型的方法来定义Interceptor。为了提供更好的灵活性，能够在方法中动态注入任意依赖服务，我们并不打算为这样的Interceptor类型定义一个接口。接口是一个契约，同时也是一个限制。如果类型实现某个接口，意味着必需按照规定的声明实现其方法，针对方法的服务注入将无法实现，所以Dora.Interception采用“基于约定”的方式来定义Interceptor类型。具体的约定如下
Interceptor只需要定义一个普通的实例类型即可。
Interceptor类型必须具有一个公共构造函数，它可以包含任意的参数，并支持构造器注入。
拦截功能实现在约定的InvokeAsync的方法中，这是一个返回类型为Task的异步方法，它的第一个参数类型为InvocationContext。
除了表示当前执行上下文的参数之外， 任何可以注入的服务于对象都可以定义成InvokeAsync方法的参数。
当前Interceptor针对后续的Interceptor或者目标方法的调用通过调用InvocationContext的ProceedAsync方法来实现。
如下所示的就是一个典型的Interceptor，它提供了针对构造函数和方法的注入。
public class FoobarInterceptor
{ public IFoo Foo { get; } public string Baz { get; }
public FoobarInterceptor(IFoo foo, string baz)
{
Foo = foo;
Baz = baz;
} public async Task InvokeAsync(InvocationContext context, IBar bar)
{ await Foo.DoSomethingAsync(); await bar.DoSomethingAsync(); await context.ProceedAsync();
}
}[1]：更加简练的编程体验
[2]：基于约定的拦截器定义方式
[3]：多样性的拦截器应用方式
[4]：与依赖注入框架的深度整合
[5]：对拦截机制的灵活定制
作者：蒋金楠
原文出处：https://www.cnblogs.com/artech/p/dora-interception-02.html
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。