依赖注入中的ASP.NET Web API处理程序和过滤器 [英] Dependency Injection for Handlers and Filters in ASP.NET Web API

查看:611
本文介绍了依赖注入中的ASP.NET Web API处理程序和过滤器的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我试图线了我的网页API项目中使用温莎城堡政府间海洋学委员会

I am trying to wire up my Web Api project to use Castle Windsor for IoC

我已经按照这个优秀的文章做到这一点对我的控制器。

I have done that for my controllers by following this excellent article.

我现在正在试图让依赖注入我的DelegatingHandler和ActionFilterAttribute

I am now trying to get dependencies injected into my DelegatingHandler and ActionFilterAttribute

我试图复制用于常规ASP.Net MVC的过滤器技术,但他们似乎不是在网页API适用

I have tried to copy the techniques used for filters in regular ASP.Net MVC but they don't seem to apply in Web Api

有没有人成功地得到这个工作?

has anyone managed to get this working?

我不知道相关的扩展点是在网页API是什么

I'm not sure what the relevant extension point is in the Web Api

我已经看到了这所建议

config.MessageHandlers.Add(_myContainer.Resolve<IApiUsageLogger>());

但不知道是否有更好的办法。
我想preFER进军创建这些处理器/过滤机制

but not sure if there is a better way. I would prefer to tap into the mechanism that creates these handlers/filters

由于这对于很多处理气味的服务定位。
是否有被创建的所有处理器的单点?

As this smells of Service Location for lots of handlers. Is there a single point that all handlers are created?

什么想法?

推荐答案

由于 MessageHandlers 收藏是全球性的,它有效地单身的列表。这是罚款时,处理程序本身没有状态,没有依赖性,但在是基于坚实的设计原理的系统,它很可能是这些处理器将拥有自己的和很可能的相关性,其中有些依赖的需要寿命比单身更短。

Since the MessageHandlers collection is global, it's effectively a list of singletons. This is fine when the handler itself has no state and no dependencies, but in a system that is based on the SOLID design principles, it's very likely that those handlers will have dependencies of their own and its very likely that some of those dependencies need a lifetime that is shorter than singleton.

如果是这样的话,这样的消息处理程序不应该被创建为单例,因为在一般情况下,一个组件不应该有一生的时间长于其依赖的生存期。

If that's the case, such message handler should not be created as singleton, since in general, a component should never have a lifetime that is longer than the lifetime of its dependencies.

网页API但是缺乏一个允许对每个请求解决此类处理器的挂钩,但这种机制很容易​​通过使用代理类创建的:

Web API however lacks any hooks that allow to resolve such handler on each request, but such mechanism is easily created by using a proxy class:

public class DelegatingHandlerProxy<TDelegatingHandler> : DelegatingHandler
    where TDelegatingHandler : DelegatingHandler
{
    private readonly WindsorContainer container;

    public DelegatingHandlerProxy(WindsorContainer container)
    {
        this.container = container;
    }

    protected override async Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        // trigger the creation of the scope.
        request.GetDependencyScope();

        var handler = this.container.Resolve<TDelegatingHandler>();

        handler.InnerHandler = this.InnerHandler;

        var invoker = new HttpMessageInvoker(handler);

        var response = await invoker.SendAsync(request, cancellationToken);

        container.Release(handler);

        return response;
    }
}

此代理可以使用如下:

GlobalConfiguration.Configuration.MessageHandlers.Add(
    new DelegatingHandlerProxy<MyCustomHandler>(myContainer));

代理是一个单身,但它会解析指定的 MyCustomHandler 上的每个请求。

这篇关于依赖注入中的ASP.NET Web API处理程序和过滤器的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆