On one of our current projects utilizing all the latest Microsoft has to offer (MVC2, EF4, Unity, .NET 4) we found ourselves creating a number of Action Filters for encapsulating often used behavior, such as Auditing, Authorization, and temp data management. Action filters are an incredibly powerful tool in MVC, capable of manipulating any piece of the request/response and making that behavior easy to reuse. The problem with Action Filters, on the surface, is that there is no immediately apparent method of injecting dependencies into those filters – they’re just attributes on a method in your controller, or on the class of the controller itself, such as below:
[Authorized] public class WidgetController : MyControllerBase { [Audit("Doing something")] public ActionResult DoSomething() { ... } }
In the case where your attribute has dependencies that should be resolved by your DI container, you may find yourself manually resolving those dependencies every time, which can get tedious and error prone. The answer to this lies in the Controller, but first we need a little background on how the Action Filters are actually executed.
When the MVC routing system finds the Controller for the current request, it uses an instance of that controller create to an ActionInvoker, which will be used in executing the action(s) on the controller. This ControllerActionInvoker is responsible for finding the appropriate action given the route on that controller, as well as invoking the action AND the actions filters. Since the ControllerActionInvoker is responsible for actually creating instances of the Filters, it’s the ideal location to put code responsible for building up the dependencies of any Filters on your action methods. With a minimal amount of code, we should be able to usurp the ActionFilter creation process and inject our dependencies before the filter executes.
First, we’ll need a DI wrapper. The one below is a snippet from mine which acts as a shell around Unity:
public static class ServiceResolver { public static T InjectDependencies(T instance) { return (T)_container.BuildUp(instance.GetType(), instance); } ... }
Now, the custom action invoker, which for these purposes only needs to override GetFilters(…), since this is the method responsible for getting the filters on a given Action:
public class MyActionInvoker : ControllerActionInvoker { protected override FilterInfo GetFilters(ControllerContext controllerContext, ActionDescriptor actionDescriptor) { var filters = base.GetFilters(controllerContext, actionDescriptor); filters.ActionFilters.ForEach( f => ServiceResolver.InjectDependencies(f)); filters.AuthorizationFilters.ForEach( f => ServiceResolver.InjectDependencies(f)); filters.ExceptionFilters.ForEach( f => ServiceResolver.InjectDependencies(f)); filters.ResultFilters.ForEach( f => ServiceResolver.InjectDependencies(f)); return filters; } }
Note that we iterate over all the different filter collections that are returned as a result of the call to base.GetFilters(…). This ensures that any filters we create for any part of the action process will have dependencies resolved. Now you need to make sure your custom ActionInvoker is used any time MVC is trying to invoke an action on your controllers, so you’ll need a common base Controller class that all of your controllers will inherit from.
public abstract class MyControllerBase : Controller { protected override IActionInvoker CreateActionInvoker() { return new MyActionInvoker(); } }
Now any ActionFilters which have property-based dependencies will be automatically fulfilled by the new ActionInvoker, such as the AuditAttribute show below:
public class AuditAttribute : System.Web.Mvc.ActionFilterAttribute { [Dependency] public IUserRepository UserRepository { get; set; } [Dependency] public ILogger Logger { get; set; } ... }













