异步/等待代码中的简单注入器拦截

时间:2016-10-05 18:30:31

标签: async-await aop simple-injector interception

我正在开始一个新项目,并且正在考虑使用Simple Injector拦截(https://simpleinjector.readthedocs.io/en/latest/InterceptionExtensions.html)来跟踪方法入口/出口以及记录参数和返回值等。我过去使用过这个拦截器并且效果很好。但我以前的项目并不是异步/等待。这个新项目有很多方法都是异步/等待,我想知道

  • 这个拦截器是否适用于async / await方法?
  • 此拦截器需要进行哪些更改才能使其适用于async / await方法?

我知道装饰器是一种比拦截更好的模式,但为我想跟踪的每个接口编写一个装饰器并不是我期待的。

更新: 我在我的异步/等待代码中尝试了这个拦截器,它确实注入了我的跟踪代码。但是,我在应用程序的某些部分得到了奇怪的结果。我没有机会深入挖掘为什么禁用拦截会使其正常工作以及为什么拦截被启用时它不会按预期工作。我的代码很可能出错了。

我希望有人在他们的代码中已经使用了这个拦截扩展,能够指出我正确的方向。

1 个答案:

答案 0 :(得分:2)

  

这个拦截器是否适用于async / await方法?

C#中的异步代码是 <a href="#" class="logo"><img class="logo_img" src="images/sw17_rebrand-logo.svg"/></a> 之上的语法糖。这意味着如果您的代码需要在调用异步方法之后执行任何有用的操作,那么您将在返回的Task上调用ContinueWith(或使用C#语法) 。如果在拦截器中考虑异步,则无法在包装对象之后执行逻辑。

为了使这项工作成功,你必须明确检查被包装的方法是否返回Task,如果是这样的话,你应该通过勾勒你的&#39;&#39;来实现异步。 ;代码使用Task

这是我认为拦截不如使用装饰器的众多原因之一。装饰器允许您的代码更清晰,避免使用反射,提供完整的编译时支持,提供更好的性能,防止不得不依赖于拦截库,并强迫您进行更加SOLID的应用程序设计。

也就是说,文档的ContinueWith在考虑异步性时会看起来如下:

MonitoringInterceptor