[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; }
...
}

                          

[HttpGet]
public virtual ActionResult LogOn()
{
	return View(Views.LogOn);
}

As opposed to:

[HttpGet]
public virtual ActionResult LogOn()
{
	return View("LogOn");
}

This post is not going into T4 templates, if you are not familiar with them check out Code Generation and Text Templates for an overview. Using them can present some challenges though and one of those is what I will be addressing in this post.

The Challenge

If you are using areas in your MVC application and you have functionality that crosses those boundaries, T4 templating causes issues when that logic needs to display views or redirect to actions for each area.

The easy solution is to have a controller that encapsulates the logic that both areas use but then you have to resort to magic strings and this could result in run-time errors if a view or action is moved or renamed later.

The Solution

What we did was simply use an abstract base controller that resides in the main controller folder of the project and created derived classes in the respective areas. The base class is where all the common logic exists and the derived classes implement the desired logic and displays the area specific views.

For example:
(In base class)

public abstract ActionResult Index();

(In derived class1)

[HttpGet]
public override ActionResult Index()
{
	return View(MVC.MainArea.Home.Views.Index, null);
}

(In derived class2)

[HttpGet]
public override ActionResult Index()
{
	return View(MVC.OtherArea.Home.Views.Index, null);
}

This allows the application to use the T4 templates and still generate compile time errors if someone changes any views or actions referenced in the derived controllers.