How do I resolve Dependency Injection in MVC Filter attributes

Question

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?

score 17 · Accepted Answer · edited Sep 29 '11 at 13:04

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.)

Thank you Nick - both for a thorough answer and a brilliant framework! — Mark, Nov 15 '10 at 07:10

David Neale · Answer 2 · 2010-11-12T12:29:14.997

2

There's no straight-forward way to do this prior to MVC2. There is an interesting technique detailed here: http://www.mattlong.com.au/?p=154. I'd suggest using the Common Service Locator to abstract over this and locate your DI container.

If you're using MVC 3 then you can use MVC Service Location

edited Nov 12 '10 at 12:29

answered Nov 12 '10 at 09:36

David Neale

16,498
6
59
85

2

What's the point of using CSL if it's service locator anyway? CSL usually is used when You know Your code is going to be reused by someone else who might prefer another container. Don't think there is another reasoning for abstracting it. – Arnis Lapsa Nov 12 '10 at 13:41
That one's been argued to death - it always comes down to a ideological point of view, – David Neale Nov 12 '10 at 13:50

score 2 · Answer 3 · answered Nov 12 '10 at 10:37

I would seem that the easiest way to achieve this is to bite the bullet and accept a dependency on autofac itself. While a dependency on the IoC is in itself an anti-pattern, it's somewhat more pallatable. You can implement a property as follows:

public class UserAuthorizeAttribute : AuthorizeAttribute
{            
    public IUserRepository CurrentUserService
    {
        get
        {
            var cpa = (IContainerProviderAccessor)HttpContext.Current.ApplicationInstance;
            var cp = cpa.ContainerProvider;
            return cp.RequestLifetime.Resolve<IUserRepository>();
        }
    }
}
     ...

score 0 · Answer 4 · answered Nov 12 '10 at 13:37

Constructor injection seems to be impossible w/o changing way of filter registration.

Even in Asp.Net Mvc3:

One place where dependency injection has been difficult in the past is inside the filter attributes themselves. Because the .NET framework runtime is actually responsible for creating these attribute instances, we cannot use a traditional dependency injection strategy.

So - next best thing is property injection (Mvc3 provides some support for that out of the box).

Here's a how to for doing that manually.

I personally use MvcExtensions. I'm fine with registering them in different way. Here's usage.

Another thing You might want to investigate is MvcTurbine project. In contrast to MvcExtensions project which is more general - MvcTurbine is primarily for providing dependency injection support.

How do I resolve Dependency Injection in MVC Filter attributes

4 Answers4

Linked