如何解决在MVC过滤器的属性依赖注入 [英] How do I resolve Dependency Injection in MVC Filter attributes

问题描述

我从AuthorizationAttribute派生的自定义属性类，它在控制器操作进行自定义的安全。该OnAuthorizationCore方法，以ajudicate用户是否可以调用操作依赖于各种其他组件（例如DAL）。

我使用Autofac依赖注入。该ExtensibleActionInvoker声称能够在行动过滤器执行财产注入。设置在运行时属性的属性（这似乎是一个坏主意）将在一个简单的单元测试工作，但在繁忙的，多线程的Web服务器它必然要出问题，所以这个想法似乎是一个反模式。因此，这个问题：

如果我在AuthorizationAttribute顺序取决于其他组件正常工作，它的权利[建筑]格局才能实现这一目标？

即。 AuthorizationAttribute取决于IUserRepository ......如何的应的这种关系来解决？

解决方案

  

该ExtensibleActionInvoker声称能够在行动过滤器执行财产注入。

正确 - 但不要与可能不实现它们的属性混淆动作过滤器。在ASP.NET MVC解决这个最彻底的方法就是分裂的责任，即使MVC框架允许你把它们混合起来。

例如，使用一对类 - 保存数据的属性类只：

  //只是一个普通的旧的属性数据值
类SomeAttribute：属性{...}
 

和已注入的依赖关系的过滤器：

  //获取依赖注入
类SomeFilter：IActionFilter {...}
 

SomeFilter 只使用正从控制器或动作方法 SomeAttribute 属性的典型方法通过 GetCustomAttributes（）做力所能及的工作是必要的。

您就可以使用 ExtensibleActionInvoker 要连接过滤器：

  builder.RegisterControllers（...）InjectActionInvoker（）。
builder.RegisterType＆LT; ExtensibleActionInvoker＆GT;（）为＆lt;＆IActionInvoker GT;（）;
builder.RegisterType＆LT; SomeFilter＆GT;（）为＆lt;＆IActionFilter GT;（）;
 

这可能是一个多一点code比你写的使用属性，作为过滤器的方法，但在code的质量将是从长远来看（例如，通过避免的局限性更好属性和服务定位器解决方案的尴尬。）

I have a custom attribute class derived from AuthorizationAttribute, which performs custom security on controller actions. The OnAuthorizationCore method depends on various other components (e.g. DAL) in order to ajudicate whether a user can invoke an action.

I'm using Autofac for dependency injection. The ExtensibleActionInvoker claims to be able to perform property injection on action filters. Setting an attribute's properties at runtime (which seems like a bad idea) will work in a simple unit test, but in a busy, multi-threaded web server it's bound to go wrong, and so this idea seems like an anti-pattern. Hence this question:

If my AuthorizationAttribute depends on other components in order to work correctly, what it the right [architecture] pattern in order to achieve this?

i.e. AuthorizationAttribute depends on IUserRepository... how should this relationship be resolved?

解决方案

The ExtensibleActionInvoker claims to be able to perform property injection on action filters.

Correct - but don't confuse action filters with the attributes that might not implement them. The cleanest way to approach this in ASP.NET MVC is to split responsibilities, even though the MVC framework allows you to combine them.

E.g., use a pair of classes - an attribute class that holds data only:

// Just a regular old attribute with data values
class SomeAttribute : Attribute { ... }

And a filter that has dependencies injected:

// Gets dependencies injected
class SomeFilter : IActionFilter { ... }

SomeFilter just uses the typical approach of getting the SomeAttribute attribute from the controller or action method via GetCustomAttributes() to do whatever work is needed.

You can then use ExtensibleActionInvoker to wire up the filter:

builder.RegisterControllers(...).InjectActionInvoker();
builder.RegisterType<ExtensibleActionInvoker>().As<IActionInvoker>();
builder.RegisterType<SomeFilter>().As<IActionFilter>();

It might be a little more code than you'd write using the attribute-as-filter approach, but the quality of the code will be better in the long run (e.g. by avoiding the limitations of attributes and the awkwardness of the Service Locator solutions.)

这篇关于如何解决在MVC过滤器的属性依赖注入的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！