Changes in this version:

• Added Silverlight compatibility
• Moved support for the CommonServiceLocator into a separate assembly
• Adding additional interfaces for some of the validators (ILengthValidator, INotNullValidator)
• AbstractValidator now implements IEnumerable<IRuleBuilder<T>>
• Added ShouldHaveValidationError extension method for testing validators

The ASP.NET MVC ModelState dictionary allows you to record validation errors which can then be displayed in your web page.

For example, imagine you add a textbox to a page using the MVC framework’s built-in HTML helpers, then this will render a standard text field:

Your name: <%= Html.TextBox("Name") %>

In your controller, if you add an error to the ModelState dictionary with the same name as the textbox, then the HTML helper will change the styling of the input field by adding a css class of “input-validation-error”.

public class HomeController : Controller {
   public ActionResult Index() {
       ModelState.AddModelError("Name", "Please enter a name");
       return View(new MyViewModel { Name = "" });
   }
}

Using the default ASP.NET MVC template, it will add a red border with a light pink background:

You can also display the actual validation errors by making use of the ValidationSummary helper:

<%= Html.ValidationSummary() %>
Enter your name: <%= Html.TextBox("Name") %>

Which will display something like this:

ModelState with FluentHtml

By default, the Fluent HTML helpers in MvcContrib do not have support for ModelState. However, it is very easy to add support for this by writing a custom MemberBehaviour (I previously wrote about extending the HTML helpers with MemberBehaviors here)

Here is the implementation of the ModelStateMemberBehavior class:

public class ModelStateMemberBehavior : IMemberBehavior {
	private readonly ModelStateDictionary modelState;
 
	public ModelStateMemberBehavior(ModelStateDictionary modelState) {
		this.modelState = modelState;
	}
 
	public void Execute(IMemberElement element) {
		ModelState state;
		if (element.Builder.Attributes.ContainsKey("name")) {
			if (modelState.TryGetValue(element.Builder.Attributes["name"], out state)) {
				element.Builder.AddCssClass("input-validation-error");
			}
		}
	}
}

This class will check whether the name of the element being rendered is present in the specified ModelState dictionary. If so, it will add a css class of “input-validation-error” to the element being rendered.

Now we need to hook this into the HTML helpers. This can be done by implementing the IViewModelContainer interface on your base View Page:

public class MyBaseViewPage<T> : ViewPage<T>, IViewModelContainer<T> where T : class {
   private List<IMemberBehavior> memberBehaviors = new List<IMemberBehavior>();
 
   protected override void SetViewData(ViewDataDictionary viewData) {
      base.SetViewData(viewData);
      behaviors.Add(new ModelStateMemberBehavior(ViewData.ModelState));
   }
 
   public T ViewModel {
      get { return ViewData.Model; }
   }
 
   public IEnumerable<IMemberBehavior> MemberBehaviors {
	get { return memberBehaviors; }
   }
}

Now, so long as all your view pages inherit from MyBaseViewPage, any calls to the fluent HTML helpers will have support for ModelState:

Your name: <%= this.TextBox(model => model.Name) %>

One of the great things about these helpers is that you can change how the HTML is rendered by writing custom IMemberBehavior objects. For example, the helpers come with a set of attributes that you can use to decorate your model:

public class Customer {
   [MaxLength(50)]
   public string Name { get; set; }
}

Then, when you render your view, the HTML helper will automatically detect the presence of this attribute and render a “maxlength” attribute accordingly. For example, this textbox helper…

<%= this.TextBox(m => m.Customer.Name) %>

…would render this html:

<input type="text" maxlength="50" id="Customer_Name" name="Customer.Name" />

I wanted to take this a step further and integrate it with my validation library, so the HTML helpers will automatically pick up maxlength/required attributes from my validator classes.

Step 1: Custom Validator Class

The first stage was to create a metadata class to hold information about a validator.

public class PropertyModel {
	public int MaxLength { get; set; }
	public bool Required { get; set; }
	public PropertyInfo Property { get; private set; }
 
	public PropertyModel(PropertyInfo property) {
		Property = property;
	}
}

Next, I introduced a new interface, IPropertyDescriptor, that all my validator classes will implement. This interface defines the signature for a method that creates PropertyModel instances based on a PropertyInfo:

public interface IPropertyDescriptor {
	PropertyModel GetPropertyModel(PropertyInfo property);
}

Next, I added a custom base-class for all my validators which implements the above interface:

public abstract class Validator<T> : AbstractValidator<T>, IPropertyDescriptor {
	public PropertyModel GetPropertyModel(PropertyInfo property) {
		var model = new PropertyModel(property);
 
		var validators = this.OfType<IPropertyValidatorContainer<T>>().Where(x => x.Property == property).Select(x => x.Validator);
		foreach (var validator in validators) {
			if (HandleLengthValidator(validator, model)) continue;
			if (HandleRequiredValidator(validator, model)) continue;
		}
 
		return model;
	}
 
	private bool HandleLengthValidator(IPropertyValidator<T> validator, PropertyModel model) {
		var length = validator as ILengthValidator;
		if(length != null) {
			model.MaxLength = length.Max;
			return true;
		}
		return false;
	}
	private bool HandleRequiredValidator(IPropertyValidator<T> validator, PropertyModel model) {
		var required = validator as INotNullValidator;
		if(required != null) {
			model.Required = true;
			return true;
		}
		return false;
	}	
}

Essentially, the GetPropertyModel method iterates through all of the property validators to see if any required or max-length validators have been defined. If so, it records them in the PropertyModel object.

I can now define my validators as usual, but they now inherit from my new Validator<T> class, rather than AbstractValidator<T>.

public class CustomerValidator : Validator<Customer> {
   public CustomerValidator() {
     RuleFor(customer => customer.Name).Length(0, 50);
   }
}

Step 2: Custom Validator Factory

The next stage is to impelement a custom validator factory that can be used to instantiate validators. For this example, I’ll be using the Windsor IoC container.

Firstly, in my application startup routine I need to register all of my validators with Windsor:

var container = new WindsorContainer();
container.Register(AllTypes.Of(typeof(IValidator<>)).FromAssembly(typeof(CustomerValidator).Assembly).WithService.Base());

Next, I create a validator factory that uses Windsor (or more accurently, Microkernel) to create the validator instances.

public class ValidatorFactory : IValidatorFactory {
	private readonly IKernel container;
 
	public ValidatorFactory(IKernel container) {
		this.container = container;
	}
 
	public IValidator<T> GetValidator<T>() {
		return container.TryResolve<IValidator<T>>();
	}
 
	public IValidator GetValidator(Type type) {
		var genericType = typeof(IValidator<>).MakeGenericType(type);
		return (IValidator)container.TryResolve(genericType);
	}
}

Note that TryResolve is an extension method on IKernel that will attept to resolve a component and return null if it fails (by default, Windsor/Microkernel will throw an exception).

This validator factory can now be registered with the container:

container.Register(Component.For<IValidatorFactory>().ImplementedBy<ValidatorFactory>());

Step 3: The PropertyModelFactory

The next stage is to create a class that can be used to locate the correct validator from a PropertyInfo object (by using the validator factory) and return a corresponding PropertyModel.

public class PropertyModelFactory : IPropertyDescriptor {
   private IValidatorFactory validatorFactory;
 
   public PropertyModelFactory(IValidatorFactory validatorFactory) {
     this.validatorFactory = validatorFactory;
   }
 
  public PropertyModel GetPropertyModel(PropertyInfo property) {
     var descriptor = validatorFactory.GetValidator(property.ReflectedType) as IPropertyDescriptor;
     if(descriptor != null) {
        return descriptor.GetPropertyModel(property);
     }
     return null;
  }
}

Again, this needs to be registered with the container:

container.Register(Component.For<IPropertyDescriptor>().ImplementedBy<PropertyModelFactory>());

Step 4: Custom IMemberBehavior

Next, we need to create a custom IMemberBehavior that will make use of the PropertyModelFactory:

public class ValidatorMemberBehaviour : IMemberBehavior {
   private readonly IPropertyDescriptor descriptor;
 
   public ValidatorMemberBehaviour(IPropertyDescriptor descriptor) {
      this.descriptor = descriptor;
   }
 
   public void Execute(IMemberElement element) {
      if (element.ForMember == null) return;
 
      var property = element.ForMember.Member as PropertyInfo;
      if(property == null) return;
 
      var model = descriptor.GetPropertyModel(property);
      if (model == null) return;
 
      var maxLengthMethod = element.GetType().GetMethod("MaxLength");
 
      if(maxLengthMethod != null) {
         element.Builder.MergeAttribute("maxlength", model.MaxLength.ToString());				
      }
      if(model.Required) {
         element.Builder.AddCssClass("required");
      }
   }
}

MemberBehaviors are invoked when certain HTML helper objects are created, so this behaviour now needs to be registered with our ViewPage:

public class MyViewPage<T> : ModelViewPage<T> where T : class {
   public MyViewPage() 
     : base(new ValidatorMemberBehaviour(ServiceLocator.Resolve<IPropertyDescriptor>())) { }
}

Note that the ServicLocator static class is just a wrapper around Windsor.

So now the HTML Helpers will use my validator definitions to generate required/maxlength attributes. I think the extensibility of these helpers is incredibly powerful and I am planning on using them going forward in my next project.

• If you say you know C# on your CV, I expect you to know it.
• If you don’t understand a question or get stuck on a test, ask for clarification.
• Just because someone has a Microsoft Certification doesn’t automatically make them a great developer.
• Not being able to diagnose the cause of a simple NullReferenceException (when you have access to a debugger and the internet) is worrying.
• Don’t just tell me what I want to hear - be honest.
• Being able to show and demonstrate a project you’ve worked on creates a great impression.
• Not being able to explain the last project you worked on creates a very bad impression.

However, if you need your action filters to do anything complex, injecting services into action filters using an Inversion of Control container (such as Windsor or StructureMap) can be painful.

Typically, when using an IoC container it is necessary to register all your components with the container up-front and then use the container to create instances for you. When the container creates the object, it will also create any required dependencies and pass them to the constructor (or property setters).

However, as ActionFilters are defined as attributes, they cannot be instantiated by the container. One solution to this problem is to wrap the container with a static class and then make use of constructor chaining to create the illusion of automatic dependency resolution:

public class LoggingFilter : ActionFilterAttribute {
  private ILogger logger;
 
  public LoggingFilter() : this(IoC.Resolve<ILogger>()) {
  }
 
  public LoggingFilter(ILogger logger) {
    this.logger = logger;
  }
 
  public override void OnActionExecuting(ActionExecutingContext context) {
    logger.log("Entering action: " + context.RouteData.GetRequiredString("action"));
  }
}

In this example, the default constructor will call into a static ‘IoC’ class (which wraps the underlying container) to resolve an ILogger instance and then pass this to the second constructor. In a unit-testing scenario, you can make use of the second constructor directly in order to supply a mocked ILogger instance.

There are several things I don’t like about this code:

1. The filter now has a coupling to the container
2. If you trigger the instantiation of the attribute without first initialising the container then this can lead to problems (eg reflecting over a method’s attributes in a unit-testing scenario)
3. It’s just plain ugly!

Thankfully, there is a better way. Several IoC containers (including Autofac and Unity) can inject services into objects using property setters without the target object needing to be registered with the container. I’ll be using Autofac for the sample code.

We can write a custom ControllerActionInvoker to make use of this feature by intercepting the action filters before they are invoked. The custom action invoker looks like this:

namespace MyApp {
  using System;
  using System.Collections.Generic;
  using System.Reflection;
  using System.Web.Mvc;
  using Autofac;
 
  public class MyActionInvoker : ControllerActionInvoker {
    private readonly IContainer container;
 
    public MyActionInvoker(IContainer container) {
      this.container = container;
    }
 
    protected override ActionExecutedContext InvokeActionMethodWithFilters(MethodInfo methodInfo, IDictionary<string, object> parameters, IList<IActionFilter> filters) {
      foreach (var filter in filters) {
        container.InjectProperties(filter);
      }
      return base.InvokeActionMethodWithFilters(methodInfo, parameters, filters);
    }
  }
}

The custom action invoker takes an instance of IContainer (the autofac container) in its constructor, which it can then use to inject services into the action filter attributes before they are invoked. This is done by overriding the InvokeActionMethodWithFilters method and calling container.InjectProperties for each object in the filters collection.

In order to get Autofac working with ASP.NET MVC, you need to register an HTTP module as well as set up the AutofacControllerFactory (instructions here.)

It is also necessary to register the custom action invoker with Autofac in your global.asax:

var builder = new ContainerBuilder();
builder.Register<MyActionInvoker>().As<IActionInvoker>().FactoryScoped();

As well as the ActionInvoker, you also need to register your controllers. Autofac contains a ‘module’ for doing this (the AutofacControllerModule), but we need to make a slight modification in order to use our custom action invoker. The modified module looks like this:

public class ControllerModule : Module {
  private readonly Assembly assembly;
  private readonly IControllerIdentificationStrategy controllerNamingStrategy = new DefaultControllerIdentificationStrategy();
 
  public ControllerModule(Assembly assembly) {
    this.assembly = assembly;
  }
 
  protected override void Load(ContainerBuilder builder) {
    var controllers = from type in assembly.GetExportedTypes()
                           where typeof(IController).IsAssignableFrom(type) 
			   where !type.IsAbstract
		           select type;
 
    foreach (var type in controllers) {
      builder.Register(type)
        .FactoryScoped()
        .As(controllerNamingStrategy.ServiceForControllerType(type))
        .As(type)
        .OnActivating(InjectInvoker);
    }
  }
 
  private void InjectInvoker(object sender, ActivatingEventArgs e) {
    ((Controller)e.Instance).ActionInvoker = e.Context.Resolve<IActionInvoker>();
  }
}

Now when a controller is instantiated, the ActionInvoker property will be set to an instance of our custom action invoker. The module should be registered with the container builder:

builder.RegisterModule(new ControllerModule(typeof(HomeController).Assembly));

So, assuming an ILogger instance is registered with the container, the sample LoggingFilter could be written like this:

public class LoggingFilter : ActionFilterAttribute {
   public ILogger Logger { get; set; }
 
  public override void OnActionExecuting(ActionExecutingContext context) {
    Logger.log("Entering action: " + context.RouteData.GetRequiredString("action"));
  }
}

Much better!

The same approach can also be used for other filter types, (such as AuthorizationFilters) by overriding the appropriate method.

Note that container.InjectProperties makes use of reflection, so there is a potetial performance issue here.

Edit (5 December 2008): Here is an extension method that adds the InjectProperties method to the Microkernel from Castle Windsor.

using System;
using System.Reflection;
using Castle.MicroKernel;
using Castle.MicroKernel.ComponentActivator;
 
public static class WindsorExtension {
	public static void InjectProperties(this IKernel kernel, object target) {
		var type = target.GetType();
		foreach(var property in type.GetProperties(BindingFlags.Public | BindingFlags.Instance)) {
			if(property.CanWrite &&  kernel.HasComponent(property.PropertyType)) {
				var value = kernel.Resolve(property.PropertyType);
				try {
					property.SetValue(target, value, null);
				}
				catch(Exception ex) {
					var message = string.Format("Error setting property {0} on type {1}, See inner exception for more information.", property.Name, type.FullName);
					throw new ComponentActivatorException(message, ex);
				}
			}
		}
	}
}

As the ModelState is part of the ViewData, it is only available for the current request. This means that you cannot redirect to another action in order to show the error summary, instead you have to render a view directly from your Save action. Personally I don’t think this is a good idea - the Save action should just try and save changes, and then redirect to another action to display validation errors.

One solution is to store the ModelState inside the TempData (as anything added to the TempData will be made available to the next HTTP request). It is possible to use an ActionFilterAttribute to make this happen automatically.

Under the covers, TempData makes use of ASP.NET Session State which means that every object that is stored in TempData needs to be marked as Serializable if you are using an out of process session store. Unfortunately, the ModelStateDictionary is not marked as serializable, so in order for this approach to work it is necessary to copy the contents of the ModelState into a temporary serializable dictionary.

I’ve made the code available in MvcContrib. You can use it by decorating your controllers with the ModelStateToTempData attribute:

using MvcContrib.Filters;
 
[ModelStateToTempData]
public class MyController : Controller {
  //...
}

The filter has the following features:

• If your controller action returns a RedirectToRouteResult, anything in the ModelState dictionary will be wrapped in a ModelStateSerializable class and stored in TempData.
• If your action returns a ViewResult, then any ModelState objects that were previously copied to TempData will be re-added to the ModelState dictionary.

Over the last couple of days I’ve spent some time refactoring it in order to support custom validator classes which can be useful in keeping your validation logic nicely hidden and out of the way.

So imagine you have a set of validation rules like this:

var person = new Person();
 
var validator = Validator.For(person).Rules(
	rule => rule.For(p => p.Forename).NotNull().Lengh(1, 50),
	rule => rule.For(p => p.Id).NotEqual(0),
	rule => rule.For(p => p.Surname).NotNull().Lengh(1, 50)
);
 
bool success = validator.Validate();

Using a custom validator, the validation rules can now be moved into a separate class:

public class MyPersonValidator : AbstractValidator<Person> {
	public MyPersonValidator() {
		RuleFor(p => p.Forename).NotNull().Lengh(1, 50);
		RuleFor(p => p.Id).NotEqual(0);
		RuleFor(p => p.Surname).NotNull().Lengh(1, 50);
	}
}

…and now the code for doing the validation is greatly simplified:

var person = new Person();
var validator = Validator.For(person);
bool success = validator.Validate();

In order for this to work you will need to register the validator class with your favourite IoC container and then tell the ValidatorFactory class to use that IoC container to instantiate the validators. Typically you would do this in your application’s startup routine - Application_Start for an ASP.NET app.

protected void Application_Start(object sender, EventArgs e) {
	//Set up windsor
	IoC.Initialise(new WindsorContainer());
	//Register the validator with Windsor
	IoC.Container.Register(
		Component.For<IValidator<Person>>().ImplementedBy<MyPersonValidator>().LifeStyle.Transient;
	);
 
	//Tell the ValidatorFactory to use Windsor to look for validators:
	JS.Validation.ValidatorFactory.Initialise(type => IoC.TryResolve(type));
}

In the above example, the IoC class is a static wrapper around the Windsor container

How does it work?

When you call Validator.For(object), the ValidatorBuilder will ask the ValidatorFactory for an IValidator<T> (where T is the object being validated), and the delegate that you passed to ValidatorFactory.Initialise() is invoked with that type as its parameter.

I decided to use this approach as I didn’t really want to create a dependency on a particular IoC container.

The validation rules defined in the validation class are combined with any rules defined by calling Validator.For(object).Rules(), so you can mix and match validation rules as necessary.

Custom Property Validators

It is also possible to create custom property validators. For example, to create a custom validator that checks whether a property’s value is not equal to “Foo”, you might do something like this:

Validator.For(person).Rules(
	rule => rule.For(p => p.Surname).NotNull().Add(new NotEqualToFooValidator());
);

NotEqualToFooValidator would be defined like so:

public class NotEqualToFooValidator : PropertyValidatorBase {
	public override bool Validate(object instance, object value) {
		if("Foo".Equals(value)) {
			Error = string.Format("'{0}' must not be equal to 'Foo'.", FieldName);
			return false;
		}
		return true;
	}
}

This can also be wrapped in an extension method…

public static class ValidatorExtensions {
	public static ILambdaPropertyValidatorBuilderWithOptions<T, TProperty> CannotBeFoo<T, TProperty>(this ILambdaPropertyValidatorBuilder<T, TProperty> builder) {
		return builder.Add(new NotEqualToFooValidator());
	}
}

…which makes thing a little more fluent:

Validator.For(person).Rules(
	rule => rule.For(p => p.Surname).NotNull().CannotBeFoo();
);

For something this simple, you’d usually use the NotEqual validator (rule.For(x => x.Surname).NotEqual(”Foo”)), but you get the idea.

Any custom property validators can also be used in conjunction with the custom validator classes I mentioned above.

NotEqualPropertyValidator

I’ve also added NotEqualProperty validator that ensures the value of one property is not equal to the value of another:

Validator.For(person).Rules(
	rule => rule.For(p => p.Forename).NotEqual(p => p.Surname);
);

As usual, the code is in my svn repository.

It turns out the HandleErrorAttribute in Preview 4 is the culprit. Previously I’d been using MvcContrib’s RescueAttribute.

It appears that the HandleError attribute only works locally - when using a remote connection the server just displays the standard HTTP 500 message (this is under IIS7 using Integrated Pipeline).

I fired up the MVC source code and removed this line from HandleErrorAttribute.cs (line 85):

filterContext.HttpContext.Response.StatusCode = 500;

After doing this, the error pages are displayed correctly.

Here’s a summary of some of the things that have changed:

• TempData finally works with out of process session state
• Filters that implement IExceptionFilter can easily catch exceptions thrown by other filters
• The RescueAttribute in MvcContrib is now an IExceptionFilter, so it can be used with classes that don’t inherit from ConventionController
• Multiple filters can now have the same sort order. This makes it easy to define a ‘default’ order, and then have other filters execute before/after
• TempData is now testable without needing to mock anything
• All the ComponentController hackery is gone - RenderAction is a much nicer alternative
• The bug that broke URL generation is fixed

Here’s what sucks with Preview 4:

• SubDataItems still doesn’t seem to work properly
• AuthorizeAttribute, OutputCacheAttribute and HandleError attribute are sealed and have no virtual methods
• The new built in Ajax support doesn’t seem to be easily replaceable with alternative libraries