The session will be live from 18:00 GMT (12:00 CST) and will last about 40 minutes. I’ll be covering the basics of using FluentValidation as well as how you can integrate it with ASP.NET MVC applications.

Since my post on Limitations of MVC2’s ModelValidatorProviders ASP.NET MVC2 RC2 has been released which addresses some of the issues that I raised in the post.

Firstly, validation in MVC2 RC2 now performs model-validation rather than input validation. This is much more in line with how FluentValidation works which makes the FluentValidation integration much more consistent with the built-in validation.

Secondly, it is now possible to disable the DataAnnotationsModelValidatorProvider’s “greedy” required rule. Out of the box, the DataAnnotationsModelValidatorProvider will *always* validate non-nullable value types, irrespective of whether the property is decorated with a [Required] attribute. This meant that you had to un-register the DataAnnotations provider if you didn’t want to get duplicate errors. It is now possible to turn this off by calling DataAnnotationsModelValidatorProvider.AddImplicitRequiredAttributeForValueTypes = false; in your application startup routine.

Finally, I added the ability to be able to execute some of FluentValidation’s Property Validators without needing to validate the entire object. This means it is now possible to stop the default “A value was required” message from being added to ModelState.

Enabling the FluentValidationModelValidatorProvider

After downloading the 1.2 beta 2 release you’ll need to add a reference to FluentValidation.dll and FluentValidation.Mvc.dll

To enable the FluentValidationModelValidatorProvider you will need to add it to the ModelValidatorProviders collection in your application startup routine:

protected void Application_Start() {
	RegisterRoutes(RouteTable.Routes);
 
	DataAnnotationsModelValidatorProvider
		.AddImplicitRequiredAttributeForValueTypes = false;
 
	ModelValidatorProviders.Providers.Add(
		new FluentValidationModelValidatorProvider(new AttributedValidatorFactory()));
}

Note that you need to pass an IValidatorFactory to the FluentValidationModelValidatorProvider so that it knows how to create your validator instances. I’m using the AttributedValidatorFactory in this example, but in a real application you would probably use an implementation that wraps an IoC container instead.

Next, you can create your model object and associated validator:

[Validator(typeof(PersonValidator))]
public class Person {
	public int Id { get; set; }
	public string Name { get; set; }
	public string Email { get; set; }
	public int Age { get; set; }
}
 
public class PersonValidator : AbstractValidator<Person> {
	public PersonValidator() {
		RuleFor(x => x.Id).NotNull();
		RuleFor(x => x.Name).Length(0, 10);
		RuleFor(x => x.Email).EmailAddress();
		RuleFor(x => x.Age).InclusiveBetween(18, 60);
	}
}

Finally, you can create the controller and associated view:

public class PeopleController : Controller {
	public ActionResult Create() {
		return View();
	}
 
	[AcceptVerbs(HttpVerbs.Post)]
	public ActionResult Create(Person person) {
 
		if(! ModelState.IsValid) {
			return View("Create", person);
		}
 
		TempData["notice"] = "Person successfully created";
		return RedirectToAction("Index");
 
	}
}

 
<%= Html.ValidationSummary() %>
 
<% using (Html.BeginForm()) { %>
	Id: <%= Html.TextBoxFor(x => x.Id) %><%= Html.ValidationMessageFor(x => x.Id) %>
	<br />
	Name: <%= Html.TextBoxFor(x => x.Name) %><%= Html.ValidationMessageFor(x => x.Name) %>			
	<br />
	Email: <%=Html.TextBoxFor(x => x.Email) %><%= Html.ValidationMessageFor(x => x.Email) %>
	<br />
	Age: <%= Html.TextBoxFor(x => x.Age) %><%= Html.ValidationMessageFor(x => x.Age) %>
 
	<br /><br />
 
	<input type="submit" value="submit" />
<% } %>

Now when you post the form MVC’s DefaultModelBinder will validate the Person object using the FluentValidationModelValidatorProvider.

Clientside Validation

This release also has preliminary support for clientside validation. This is enabled by calling <% Html.EnableClientValidation(); %> in your views. At the moment, only the NotNull, NotEmpty, RegularExpression and Length validators are supported.

Note that if you try to use the clientside validation support with the default error messages, you will see error messages like this:

'{PropertyName}' must not be empty.

This is because FluentValidation uses templated error messages but the MVC Framework’s clientside validation runner does not know how to correctly format these. For now, the only workaround is to explicitly specify the error message:

RuleFor(x => x.Surname).NotNull().WithMessage("'Surname' must not be empty");

For FluentValidation 1.3 I will consider providing a customised version of MVC’s MicrosoftMvcValidation.js that knows how to properly format FluentValidation error templates.

Metadata Support

Out of the box, MVC2 allows you to use the DataAnnotations attributes to provide metadata for editor/display templates. This release of FluentValidation allows you to use extra extension methods on your validator classes to define metadata using method chaining.

Firstly, you will need to replace the DataAnnotationsModelMetadataProvider with the new FluentValidationModelMetadataProvider in your Application_Start:

ModelMetadataProviders.Current = new FluentValidationModelMetadataProvider(
	new AttributedValidatorFactory());

Now you can start using the metadata extension in your validator classes (you will need to import the FluentValidation.Mvc.MetadataExtensions namespace):

public CustomerValidator() {
   RuleFor(x => x.Surname)
      .NotNull() //regular validator
      .UIHint("Surname"); //MVC Metadata
}

The FluentValidationModelMetadataProvider currently supports the following metadata-related extension methods which correspond to the DataAnnotations attributes with the same name:

• HiddenInput
• UIHint
• Scaffold
• DataType
• DisplayName
• DisplayFormat
• ReadOnly

Edit: 8th FebNote that there is a bug in the current beta build where MetaData won’t work in some circumstances. This is already fixed for the next beta, so you may want to use the latest binaries from the build server.

As usual, binaries are on CodePlex and the source is on GitHub.

• Part 1 – DataContext Per Request
• Part 2 – AutoCommit and the RoutePreParser
• Part 3 – DataLoadOptions per Request

Code for this series is available here.

One common problem when using an ORM is the issue of “select n+1″. For example, take the following Linq to Sql query:

var context = new BlogDataContext();
var posts = context.Posts;
 
foreach(var post in posts) {
   foreach(var comment in post.Comments) {
     var commenter = comment.Commenter.Name;
     Console.WriteLine("User {0} commented on post {1}", commenter, post.Title);
   }
}

This might look fine on the surface, but by default Linq to Sql will lazily-load all associations. This means that for each post loaded from the database Linq to Sql will issue a query to load the comments, and for each comment Linq to Sql will issue another query to load the commenter. So if you have 10 posts, and each post has 5 comments then you’ll end up making 61 queries to the database (1 for the posts, 1 for each post to get the comments, and 1 for each comment to get the user)

This can be mitigated by using DataLoadOptions to eagerly load all of the data in a single query:

var context = new BlogDataContext();
 
var options = new DataLoadOptions();
options.LoadWith<Post>(p => p.Comments);
options.LoadWith<Comment>(c => c.Commenter);
context.LoadOptions = options;
 
var posts = context.Posts;
foreach(var post in posts) {
 //...
}

The Problem

However, once a query has been executed, the LoadOptions property of a DataContext is frozen – you cannot then specify any additional eager loading paths.*

If you’re using a DataContext per request as per my previous post then this can be a problem. For example, imagine you have the following controller action:

public class PostsController : Controller {
  private BlogDataContext context;
 
  public PostsController(BlogDataContext context) {
     this.context = context; //injected via our IoC container
  }
 
  public ActionResult Show(int id) {
    var options = new DataLoadOptions();
    options.LoadWith<Post>(p => p.Comments);
    options.LoadWith<Comment>(c => c.Commenter);
 
    context.LoadOptions = options;
 
    var post = context.Posts.Single(p => p.Id == id);
    return View(post);
  }
}

…then this will work as expected. But now imagine your action is decorated by an ActionFilter:

[LoadCurrentUser]
public ActionResult Show(int id) { 
  //...
}

…and let’s assume that our LoadCurrentUser filter attempts to load the details of the current user from the database and store them in ViewData:

public class LoadCurrentUserAttribute : ActionFilterAttribute {
	public override void OnActionExecuting(ActionExecutingContext filterContext) {
		var context = ObjectFactory.GetInstance<BlogDataContext>();
		var identity = filterContext.HttpContext.User.Identity;
 
		if (identity.IsAuthenticated) {
			var currentUser = context.Users.Single(x => x.UserName == identity.Name);
			filterContext.Controller.ViewData["CurrentUser"] = currentUser;
		}
	}
}

Now when the controller is executed we will get the following error:

Setting load options is not allowed after results have been returned from a query.

This happens because we’re trying to set the LoadOptions for the Post after the LoadCurrentUser filter already executed a query.

The Solution

The approach I use to work around this problem is to use a custom AuthorizationFilter in conjunction with an eager loading specification.

First, we define an interface for eager loading specifications:

public interface IEagerLoadingSpecification {
  void Build(DataLoadOptions options);
}

Next, we can write some classes that implement IEagerLoadingSpecification that define particular specifications for eager loading. Using the example above, we have PostWithComments and CommentWithCommenter:

public class PostWithComments : IEagerLoadingSpecification {
  public void Build(DataLoadOptions options) {
    options.LoadWith<Post>(p => p.Comments);
  }
}
 
public class CommentWithCommenter : IEagerLoadingSpecification  {
  public void Build(DataLoadOptions options) {
     options.LoadWith<Comment>(c => c.Commenter);
  }
}

Next, we write an EagerlyLoadAttribute which implements IAuthorizationFilter and takes an array of Types in its constructor:

public class EagerlyLoadAttribute : FilterAttribute, IAuthorizationFilter {
  private Type[] types;
 
  public EagerlyLoadAttribute(params Type[] types) {
    this.types = types;
  }
 
  public void OnAuthorization(AuthorizationContext filterContext) {
    var loadOptions = new DataLoadOptions();
    var context = ObjectFactory.GetInstance<BlogDataContext>();
 
    foreach(var type in types) {
       if(! typeof(IEagerLoadingSpecification).IsAssignableFrom(type)) {
          throw new InvalidOperationException(string.Format("Type {0} does not implement IEagerLoadingSpecification", type));
       }
 
      var spec = (IEagerLoadingSpecification)Activator.CreateInstance(type);
      spec.Build(loadOptions);
    }
 
   context.LoadOptions = loadOptions;
  }
}

So what does this filter do? Firstly, because it implements IAuthorizationFilter this means it will be invoked before any action filters that decorate your controller action. When OnAuthorization is invoked, it loops over each of the Types that we’ve passed to its constructor, instantiates them and casts them to IEagerLoadingSpecification. Next, a single DataLoadOptions instance is passed to each of the specifications in turn so they can build up the required eager loading paths.

The end result is that you can now define your actions like this:

  [EagerlyLoad(typeof(PostWithComments), typeof(CommentWithCommenter))]
  [LoadCurrentUser]
  public ActionResult Show(int id) {
    var post = context.Posts.Single(p => p.Id == id);
    return View(post);
  }

Because the EagerlyLoadAttribute is an IAuthorizationFilter, it will be invoked before anything else meaning that by the time both our LoadCurrentUser filter and the Show action are invoked the DataLoadOptions have already been set on our DataContext.

* Note that other ORMs like NHibernate, LLBLGen and the Entity Framework don’t have this problem because they allow eager loading paths to be specified at the query level.

If you’ve used JetBrains’ ReSharper before, you can think of SQL Search like ReSharper’s Go to Type functionality, but for SQL Server objects rather than classes. When you hit Ctrl+Alt+D you can begin typing the first few characters of an object name and it will list all the matches for you:

Hitting ‘enter’ will take you to the selected object in the Object Explorer.

As a heavy keyboard user, I find this much more usable than navigating the Object Explorer with a mouse (especially for larger databases).

The only complaint I’d have is that the filtering options aren’t fine-grained enough. At the moment, you can filter the list on one of the following options:

…but I’d find it more useful if you could pick multiple criteria (for example, I’d like to search the names of Tables, Views and Procedures, but not include Constraints and Triggers). Hopefully this will be added for the next version.

• Part 1 – DataContext Per Request
• Part 2 – AutoCommit and the RoutePreParser
• Part 3 – DataLoadOptions per Request

Code for this series is available here.

In my previoust post, I demonstrated how you could scope a Linq to Sql DataContext to a single HTTP Request by using StructureMap to manage the lifetime of the DataContext instance. This often works well, but has a couple of gotchas. Let’s take a look at an example:

public class PostController : Controller {
	private readonly BlogDataContext context;
 
	public PostController(BlogDataContext context) {
		this.context = context;
	}
 
	public ActionResult Create() {
		return View();
	}
 
	[AcceptVerbs(HttpVerbs.Post), AutoCommit]
	public ActionResult Create(Post post) {
		context.Posts.InsertOnSubmit(post);
		return RedirectToAction("Show", new{ id = post.Id });
	}
 
	public ActionResult Show(int id) {
		var post = context.Posts.SingleOrDefault(x => x.Id == id);
		if (post == null) {
			throw new HttpException(404, "The post could not be found.");
		}
 
		return View(post);
	}
}

In this example, we have a Post controller for our fictional Blog database. The Create action renders a view where the user can create a new Post and then sends an HTTP POST to the other overload to the Create action (decorated with AcceptVerbs(HttpVerbs.Post)).

This action is decorated with the AutoCommit attribute from my previous post so that SubmitChanges will automatically be called on our DataContext. We then redirect to the “Show” action passing the Id of the newly created post in the route data.

The Show action loads the Post from the database with the corresponding Id and displays it to the user. If a post with the specified Id could not be found, it will throw a 404 exception.

There is a bug here that may not be immediately obvious. Assume that the Post’s Id property is generated by an auto-incrementing Identity field in the database. If you were to run this application and create a new Post, the Show action will always throw 404 even though the Post has been successfully created.

This happens because of when SubmitChanges is called. Our AutoCommit filter is invoked after the action has finished executing this means that at the time we call RedirectToAction(“Show”, new{ id = post.Id }) the new post has not yet been saved, so its Id will be 0.

Linq to Sql will not update the Id property until after SubmitChanges is called, which is too late in the process. The user will end up being redirected to Post/Show/0 instead of using the Id of the newly created post.

The simple workaround is to call SubmitChanges directly inside the action:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(Post post) {
	context.Posts.InsertOnSubmit(post);
 
	if (ModelState.IsValid) {
		using (var transaction = new TransactionScope()) {
			context.SubmitChanges();
			transaction.Complete();
		}
	}
 
	return RedirectToAction("Show", new { id = post.Id });
}

…but this then makes our AutoCommit attribute useless and also makes the controller action significantly more complex.

However, there is another approach we could use which still allows us to use the AutoCommit attribute. To understand this, we first need to look at the order in which things are happening when our action is invoked:

1. The IoC container creates our DataContext
2. The controller is instantiated and the DataContext is passed to its constructor
3. The Create action is invoked with a Post instance created by MVC’s DefaultModelBinder
4. The post is attached to the DataContext by calling InsertOnSubmit
5. A RedirectToRouteResult is created by calling “RedirectToAction” with a dictionary of route values
6. The AutoCommit attribute calls SubmitChanges to our DataContext
7. The Post is written to the database
8. ExecuteResult on RedirectToRouteResult is invoked
9. The Redirect URL is generated by the RouteCollection
10. The user’s browser is redirected to this URL

Instead of passing the Post Id (which will be 0) to RedirectToAction, we could pass the entire post instance. After the post has been saved we can then *replace* the post instance in the RouteValueDictionary with the post’s Id before the URL is generated. This can be done by intercepting the RouteValueDictionary just before the URL is generated.

Introducing the RoutePreParser

The first thing we need is a way to identify how an object (in this case, our Post) should be converted to a route value. To do this, we can create an interface, IUrlRoutable:

public interface IUrlRoutable {
	object GetRouteParameter();
}

…and we can implement this interface in our Post class:

public partial class Post : IUrlRoutable {
	public object GetRouteParameter() {
		return Id;
	}
}

Next we can create a “fake” route. This route never generates a URL or handles a request – it is merely used to intercept the RouteValueDictionary before a URL is generated:

public class RoutePreParser : RouteBase {
	public override RouteData GetRouteData(HttpContextBase httpContext) {
		return null;
	}
 
	public override VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values) {
		var query = from pair in values
				where pair.Value != null
				let routable = pair.Value as IUrlRoutable
				where routable != null
				select new { pair.Key, Value = routable.GetRouteParameter() };
 
		foreach (var pair in query.ToList()) {
			values[pair.Key] = pair.Value;
		}
 
		return null;
	}
}

Here we loop through each key-value pair in the RouteValueDictionary. If the value implements IUrlRoutable then we call GetRouteParameter on that object and replace the original value in the RouteValueDictionary with the result of this method.

Next, we have to add the fake route to the RouteCollection in Application_Start. Note that this must be the first route added so that it gets a chance to intercept the RouteValueDictionary.

public static void RegisterRoutes(RouteCollection routes) {
	//Add our fake route first
	routes.Add(new RoutePreParser());
 
	routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
 
	routes.MapRoute(
		"Default", // Route name
		"{controller}/{action}/{id}", // URL with parameters
		new { controller = "Home", action = "Index", id = "" } // Parameter defaults
	);
}

Now, in our controller action we change the Create action to store the Post instance in the route values:

[AcceptVerbs(HttpVerbs.Post), AutoCommit]
public ActionResult Create(Post post) {
	context.Posts.InsertOnSubmit(post);
	return RedirectToAction("Show", new{ id = post });
}

…and everything now works as expected.

To recap, this is the new chain of events:

1. The IoC container creates our DataContext
2. The controller is instantiated and the DataContext is passed to its constructor
3. The Create action is invoked with a Post instance created by MVC’s DefaultModelBinder
4. The post is attached to the DataContext by calling InsertOnSubmit
5. A RedirectToRouteResult is created by calling “RedirectToAction” with a dictionary of route values. (The “Id” parameter is our new Post instance.)
6. The AutoCommit attribute calls SubmitChanges to our DataContext
7. The Post is written to the database
8. The Post instance stored in the RouteValueDictionary automatically has its Id property updated
9. ExecuteResult on RedirectToRouteResult is invoked
10. Our RoutePreParser inspects the RouteValueDictionary.
11. GetRouteParameter on Post is invoked, returning the now-populated Post Id
12. The RoutePreParser removes the Post instance from the RouteValueDictionary
13. The RoutePreParser inserts the Post Id as the “id” in the RouteValueDictionary
14. The (now correct) redirect URL is generated by the RouteCollection
15. The user’s browser is redirected to this URL

• Part 1 – DataContext Per Request
• Part 2 – AutoCommit and the RoutePreParser
• Part 3 – DataLoadOptions per Request

Code for this series is available here.

When using an ORM tool within a web application, it’s often common to scope a unit of work to the lifetime of an HTTP Request. If you’re using Linq to Sql and ASP.NET MVC, you can achieve this by using an Inversion of Control container in conjunction with an ActionFilter.

For this example, I’m going to be using the StructureMap IoC container alongside a fictional “Blog” database.

Firstly, you’ll need to configure StructureMap by calling ObjectFactory.Configure inside your Global.asax passing in a custom Registry instance:

protected void Application_Start() {
	RegisterRoutes(RouteTable.Routes);
 
	ObjectFactory.Configure(cfg => {
		cfg.AddRegistry(new MyRegistry());
	});
}

The code for MyRegistry looks like this:

public class MyRegistry : Registry {
	public MyRegistry() {
		For<BlogDataContext>()
			.HttpContextScoped()
			.Use(c => new BlogDataContext());
 
		Scan(scan => {
			scan.AddAllTypesOf<Controller>();
		});
	}
}

Here I’m telling StructureMap to create one instance of my BlogDataContext per HTTP Request as well as registering each Controller instance with the container.

Next, we need to tell MVC to use StructureMap to instantiate our controllers. This can be done by creating a custom ControllerFactory:

public class StructureMapControllerFactory : DefaultControllerFactory {
	protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType) {
		return (IController) ObjectFactory.GetInstance(controllerType);
	}
}

We can then replace the DefaultControllerFactory with the StructureMapControllerFactory in our Application_Start:

protected void Application_Start() {
	RegisterRoutes(RouteTable.Routes);
 
	ObjectFactory.Configure(cfg => {
		cfg.AddRegistry(new MyRegistry());
	});
 
	ControllerBuilder.Current.SetControllerFactory(
		new StructureMapControllerFactory());
}

Now, if we create a PostController (for creating and editing Posts in our fictional blog), we can now take a BlogDataContext in the constructor (for better testability, you’d probably want to hide the DataContext behind an interface):

public class PostController : Controller {
	private readonly BlogDataContext context;
 
	public PostController(BlogDataContext context) {
		this.context = context;
	}
 
	public ActionResult Edit(int id) {
		var post = context.Posts.Single(x => x.Id == id);
		return View(post);
	}
}

Now, visiting http://mysite/Post/Edit/1 would return a view to display a post with the Id of 1 (assuming the appropriate Post exists in the database).

Automatically Submitting Changes

We can take this a stage further by adding an ActionFilter to our application that will automatically call SubmitChanges on our DataContext at the end of the HTTP Request:

public class AutoCommitAttribute : ActionFilterAttribute {
	public override void OnActionExecuted(ActionExecutedContext filterContext) {
		if (filterContext.Controller.ViewData.ModelState.IsValid) {
			var currentDataContext = ObjectFactory.GetInstance<BlogDataContext>();
 
			using (var transaction = new TransactionScope()) {
				currentDataContext.SubmitChanges();
				transaction.Complete();
			}
		}
	}
}

Here we call into StructureMap to retrieve our current DataContext and commit any changes back to the database inside a transaction. Note that this will only happen if the ModelState is valid (ie there are no validation errors).

Another thing to keep in mind that using an IoC container as a Service Locator (as we’re doing in this filter) is generally considered bad practice. There are ways around this but these are outside the scope of this post.

Now, whenever we make a change to one of our entities the change will automatically be committed to the database provided the action is decorated with the AutoCommit attribute:

[AcceptVerbs(HttpVerbs.Post), AutoCommit]
public ActionResult Create(Post post) {
	context.Posts.InsertOnSubmit(post);
	return RedirectToAction("Index");
}

This release contains several new features:

Setting the validator cascade mode

In v1.1, if you have multiple validators defined on a single property then all of those validators will be executed even if the first one fails. This can be changed by calling the Cascade method:

RuleFor(x => x.Surname)
  .Cascade().StopOnFirstFailure()
  .NotNull()
  .Length(1, 250);

In this case, the Length validator would not be run on the Surname property if the NotNull validator fails.

This is customisable globally by setting the static property ValidatorOptions.CascadeMode.

MVC2 Support

The FluentValidationModelBinder has been modified to work with ASP.NET MVC2 RC. Note that if you want to use FluentValidation with MVC1, you will need to use the older 1.1 release.

FluentValidation 1.2 Beta 1 does not currently include the custom ModelMetadataProvider and ModelValidatorProvider that I mentioned in this post.

In its current state, the MVC2 metadata API is not extensible enough to work well with FluentValidtion (see this post for details) so I’ve omitted them from this beta. If MVC2’s support for external frameworks is improved before RTM, then I will consider re-adding these features for the next release.

Custom user state

Custom user state can be stored alongside validation failures:

RuleFor(person => person.Surname).NotNull().WithState(person => "foo")

This state can then be retrieved from the ValidationFailure object if the rule fails:

var result = validator.Validate(model);
var error = result.Errors[0];
var customState= error.CustomState;

OnAnyFailure

Rules can define a callback method that will be invoked if any of the validators associated with a particular rule fail:

RuleFor(person => person.Surname).NotNull().OnAnyFailure(person => {
   Console.WriteLine("#fail");
});

WithPropertyName

The WithPropertyName method can be used to override the name of the property that will be used when associating an error message with a particular property:

public class PersonValidator : AbstractValidator<Person> {
  public PersonValidator() {
    RuleFor(person => person.Surname).NotNull().WithPropertyName("foo");
  }
}
var validator = new PersonValidator();
var result = validator.Validate(new Person());
//property name is 'foo' instead of 'Surname'
string propertyName = result.Errors.Single().PropertyName;

InlineValidator

The InlineValidator can be used to define rules without creating a dedicated validator class:

var validator = new InlineValidator<Person>() {
  v => v.RuleFor(x => x.Surname).NotNull();
  v => v.RuleFor(x => x.Age).GreaterThan(0);
}

ValidateAndThrow

The ValidateAndThrow extension method can be used to throw an exception when validation fails rather than returning a ValidationResult.

Experimental xVal integration

Thanks to Adam Schroder, FluentValidation now includes experimental support for generating xVal rules. I’ve labelled this as “Experimental” as there is currently no support for custom validation messages or some of the more complex FluentValidation rules. The future of the FluentValidation xVal integration also depends on what happens with MVC2’s validation providers and whether xVal will continue to be developed after the MVC2 release.

New PropertyValidator base class (potentially breaking change)

In FluentValidation 1.x, all property validators implemented the IPropertyValidator<T,TProperty> interface. As of v1.2 this has been deprecated in favour of the PropertyValidator base class. Note that property validators themselves are no longer generic, which makes them easier to work with if you need to gather metadata about a validator.

For example, in v1.1 the NotNullValidator looked like this:

[ValidationMessage(Key = "notnull_error")]
public class NotNullValidator<T, TProperty> : IPropertyValidator<T, TProperty> {
	public PropertyValidatorResult Validate(PropertyValidatorContext<T, TProperty> context) {
		if (context.PropertyValue == null) {
			var formatter = new MessageFormatter().AppendProperyName(context.PropertyDescription);
			string error = context.GetFormattedErrorMessage(typeof(NotNullValidator<T, TProperty>), formatter);
 
			return PropertyValidatorResult.Failure(error);
		}
		return PropertyValidatorResult.Success();
	}
}

…while in v1.2 it now looks like this:

public class NotNullValidator : PropertyValidator, INotNullValidator {
	public NotNullValidator() : base(() => Messages.notnull_error) {
		SupportsStandaloneValidation = true;
	}
 
	protected override bool IsValid(PropertyValidatorContext context) {
		if (context.PropertyValue == null) {
			return false;
		}
		return true;
	}
}

The use of a base class helps keep the validator definitions simple. Also note that the ValidationMessage attribute has been removed – localised error messages can now be specified either by passing a resource type and key to the base PropertyValidator constructor or by using a lambda expression.

If you have written any custom property validators, it is recommended that you change them to inherit from PropertyValidator. However, there is a backwards compatibility layer in place which should allow old-style property validators to continue working.

DefaultResourceManager has been removed (breaking change)

In order to add better localization support, the DefaultResourceManager has been removed in favour of Visual Studio’s default generated “Messages” class. If you need to replace this with your own Messages class, you can set the static ResourceProviderType property on the ValidatorOptions class.

I wanted to try and write one of these for FluentValidation (see this post) but after trying this it has become quite clear that the ModelValidatorProvider API does have some limitations which have caused me some problems.

Problem 1: Property-level validation

To understand this problem, first we need to look at how different validation frameworks perform their work.

When using FluentValidation, the validators work against a pre-populated object. For example:

public class CustomerValidator : AbstractValidator<Customer{ 
  public CustomerValidator() {
     RuleFor(x => x.Surname).NotNull();
     RuleFor(x => x.CreditLimit).GreaterThanOrEqualTo(0);
  }
}
 
var customer = new Customer { CreditLimit = -1, Surname = null };
var validator = new CustomerValidator();
var results = validator.Validate(customer);

You cannot reliably validate individual properties by themselves because they may have dependencies on *other* properties being set. For example:

RuleFor(x => x.Surname).NotEqual(x => x.Forename);

This rule says tht the Surname and Forename properties must not be equal. In this case, you cannot validate the surname property by itself without having first set the value for the Forename property. Other validation frameworks (eg the Castle Project’s validation attributes) work in a similar way.

The MVC Framework’s DefaultModelBinder is primarily designed to work with the System.ComponentModel.DataAnnotations attributes. These work in a different way – they validate individual values, not the entire object. To support this, the DefaultModelBinder allows validating both the individual property values (in the OnPropertyValidated method) as well as validating the entire instance (in the OnModelUpdated method).

Here are the relevant methods from DefaultModelBinder:

//OnPropertyValidated - called for each property being bound.
protected virtual void OnPropertyValidated(ControllerContext controllerContext, ModelBindingContext bindingContext, PropertyDescriptor propertyDescriptor, object value) {
    ModelMetadata propertyMetadata = bindingContext.PropertyMetadata[propertyDescriptor.Name];
    propertyMetadata.Model = value;
    string modelStateKey = CreateSubPropertyName(bindingContext.ModelName, propertyMetadata.PropertyName);
 
    // run validation
    foreach (ModelValidator validator in propertyMetadata.GetValidators(controllerContext)) {
        foreach (ModelValidationResult validationResult in validator.Validate(bindingContext.Model)) {
            bindingContext.ModelState.AddModelError(CreateSubPropertyName(modelStateKey, validationResult.MemberName), validationResult.Message);
        }
    }
 
    // only add a "value was required" error message if there were no validation errors
    if (bindingContext.ModelState.IsValidField(modelStateKey)) {
        if (value == null && !TypeHelpers.TypeAllowsNullValue(propertyDescriptor.PropertyType)) {
            bindingContext.ModelState.AddModelError(modelStateKey, GetValueRequiredResource(controllerContext));
        }
    }
}

//OnModelUpdated - called once the entire object has been bound. 
protected virtual void OnModelUpdated(ControllerContext controllerContext, ModelBindingContext bindingContext) {
    IDataErrorInfo errorProvider = bindingContext.Model as IDataErrorInfo;
    if (errorProvider != null) {
         string errorText = errorProvider.Error;
         if (!String.IsNullOrEmpty(errorText)) {
            bindingContext.ModelState.AddModelError(bindingContext.ModelName, errorText);
          }
    }
 
    if (!IsModelValid(bindingContext)) {
        return;
    }
 
    foreach (ModelValidator validator in bindingContext.ModelMetadata.GetValidators(controllerContext)) {
        foreach (ModelValidationResult validationResult in validator.Validate(null)) {
            bindingContext.ModelState.AddModelError(CreateSubPropertyName(bindingContext.ModelName, validationResult.MemberName), validationResult.Message);
        }
    }
}

On first glance, this looks like it will work. When OnPropertyValidated calls GetValidators, I can return an empty collection of validators and do all of my work in a single validator in OnModelUpdated. Unfortunately, this does not work.

See the end of OnPropertyValidated? Here, it checks if there have been any validation errors for the property and if not then it will go ahead and run its own built-in field validation anyway for non-nullable value types – it will put a message saying “A value was required” into ModelState. And you can’t turn this off. The *only way* to stop this built-in validation is to support property-level validation in your custom ValidatorProvider. Not very useful if the underlying framework does not support this.

To work around the above issue, I ended up adding property-level validation to FluentValidation, but this is not a completely reliable solution because of the issues related to cross-property validation I mentioned above.

Problem 2: The DataAnnotationsModelValidatorProvider is greedy

The next problem that I ran into is that the DataAnnotationsModelValidatorProvider will always run required field validation, even if you’re not using the DataAnnotations attributes!

Here is an example that uses FluentValidation to validate an object where a null value is being bound to a non-nullable value type:

[Validator(typeof(FooValidator))]
public class Foo {
	public int Id { get; set; }
}
 
public class FooValidator : AbstractValidator<Foo> {
	public FooValidator() {
		RuleFor(x => x.Id).NotEmpty();
	}
}
 
[Test]
public void AddsOneError() {
	var foo = new Foo();
 
	ModelValidatorProviders.Providers.Add(
		new FluentValidationModelValidatorProvider(new AttributedValidatorFactory())
	);
 
	var meta = ModelMetadataProviders.Current.GetMetadataForProperty(() => null, typeof(Foo), "Id");
	var validators = ModelValidatorProviders.Providers.GetValidators(meta, new ControllerContext());
 
	var results = validators.SelectMany(x => x.Validate(foo)).ToList();
 
	Assert.AreEqual(1, results.Count()); //fails - 2 instead of 1
}

This test fails because there are two error messages rather than one:

The Id field is required.
'Id' should not be empty.

…the first of these errors comes from the DataAnnotationsModelValidatorProvider even though I have NOT decorated the Id property with a [Required] attribute.

Why does this happen? The answer is in DataAnnotationsModelValidatorProvider’s GetValidators method:

 if (metadata.IsRequired && !attributes.Any(a => a is RequiredAttribute)) {
       attributes = attributes.Concat(new[] { new RequiredAttribute() });
 }

This checks to see if the property is a non-nullable type and it does not have a RequiredAttribute, then it assumes that the property should have a RequiredAttribute anyway!
You can work around this by removing the DataAnnotationsModelValidatorProvider:

ModelValidatorProviders.Providers.Clear();
ModelValidatorProviders.Providers.Add(
	new FluentValidationModelValidatorProvider(new AttributedValidatorFactory())
);

…and the test now passes.

Unfortunately, this is far from ideal. This means you cannot use the DataAnnotations attributes to validate one model and a custom provider for a different model. You have to choose one or the other.

One way to work around this problem is to use a composite validator provider that wraps the underlying providers:

public class CompositeValidatorProvider : ModelValidatorProvider {
	public static void Bootstrap(ModelValidatorProviderCollection providerCollection, params ModelValidatorProvider[] customProviders) {
		var validators = customProviders.ToList();
		validators.AddRange(providerCollection);
		providerCollection.Clear();
		providerCollection.Add(new CompositeValidatorProvider(validators));
	}
 
	readonly IEnumerable<ModelValidatorProvider> innerInnerProviders;
 
	protected CompositeValidatorProvider(IEnumerable<ModelValidatorProvider> innerProviders) {
		this.innerInnerProviders = innerProviders;
	}
 
	public override IEnumerable<ModelValidator> GetValidators(ModelMetadata metadata, ControllerContext context) {
		foreach(var provider in innerInnerProviders) {
			var validators = provider.GetValidators(metadata, context).ToList();
			if(validators.Count > 0) {
				return validators;	
			}
		}
 
		return Enumerable.Empty<ModelValidator>();
	}
}

This custom provider can be used to wrap the built-in providers (including the DataAnnotations provider) as well as your own custom providers. In its GetValidators method, it iterates over each of the inner providers and asks each one to create a collection of validators. It only returns validators from the first provider that returns a non-empty collection. This means that if your custom provider can validate the object then the DataAnnotations provider will not be executed.

Now, the following test passes:

[Test]
public void AddsOneError() {
	var foo = new Foo();
 
    	var fluentProvider = new FluentValidationModelValidatorProvider(new AttributedValidatorFactory());
 
	CompositeValidatorProvider.Bootstrap(ModelValidatorProviders.Providers, fluentProvider);
 
	var meta = ModelMetadataProviders.Current.GetMetadataForProperty(() => null, typeof(Foo), "Id");
	var validators = ModelValidatorProviders.Providers.GetValidators(meta, new ControllerContext());
 
	var results = validators.SelectMany(x => x.Validate(foo)).ToList();
 
	Assert.AreEqual(1, results.Count());
}

This raises the question: if you have to resort to doing this, what is the point in allowing multiple validation providers to be registered in the first place?

I am really hoping that the MVC team will fix this fairly significant problem before RTM, but as MVC2 is already at the RC stage I think this will be unlikely.

For those not familiar with Phantom, this is a build system written in C# and Boo.

• Binaries
• Documentation
• Source

This release includes:

NAnt Integration

You can now execute NAnt tasks from within Phantom build scripts. In order for this to work, you’ll need to drop Phantom.Integration.Nant.dll and NAnt.Core.dll into the same directory as Phantom.exe. Once in place, you can import the NAnt tasks. This example executes the ‘echo’ task which is part of NAnt.Core.dll:

import tasks from NAnt.Core
target default:
   echo(message : "Hello from NAnt!")

Runnables

With v0.1 of Phantom, a lot of options were passed to helper methods via Hashes. For example, if you wanted tell msbuild to compile a project with a particular configuration and verbosity, you’d have to do the following:

msbuild("foo.sln", { "configuration": "release", "verbosity": "normal" })

With Phantom 0.2, most of these methods have been converted to classes that define regular properties. You can use Boo’s object initializer syntax they can still be declared on one line:

msbuild(file: "foo.sln", configuration: "release", verbosity: "normal")

This is called a ‘runnable’ as the msbuild class implements the IRunnable interface. When Phantom sees an instance of an IRunnable type being created, it will automatically call the ‘Run’ method (in this case, to kick off MSbuild). This syntax is equivalent to the following:

m = msbuild()
m.file = "foo.sln"
m.configuration = "release"
m.verbosity = "normal"
m.Run()

Runnables can also be used inside a with block:

with msbuild():
  .file = "foo.sln"
  .verbosity = "normal"
  .configuration = "release"

…and the ‘Run’ method will automatically be called at the end of the block. This is particularly useful if you have lots of properties that you want to set that cannot all fit on one line.

Improved FileList support

The 0.1 version of FileLists were rather limited. With 0.2 they now support exclusion patterns as well as recursively copying subdirectories:

with FileList("path/to/bin/debug"):
  .Include("**/*")
  .ForEach def(file):
    file.CopyToDirectory("directoryToPackage")

NCover Integration

Phantom 0.2 now includes runnables for executing NCover and NCoverExplorer. At present, these only work with the free Community Edition of NCover.

Continuous builds can still be downloaded from my build server.

Documentation, discussions and the issue tracker will still remain on the CodePlex site, but if you want to play with the source code then you’ll need to head over to GitHub instead. If you have not used Git before then I recommend reading my Git Guide (the guide was written for the MvcContrib project, but all the concepts apply to FluentValidation too).

What’s coming with v1.2?

The upcoming release of FluentValidation (v1.2) will have several changes including the following:

A custom ModelMetadataProvider

The FluentValidationModelMetadataProvider will allow you to define ASP.NET MVC Metadata inside your validator classes, eg:

public CustomerValidator() {
   RuleFor(x => x.Surname)
      .NotNull() //regular validator
      .UIHint("Surname"); //MVC Metadata
 
}

The FluentValidationModelMetadataProvider will support the following metadata-related extension methods:

• HiddenInput
• UIHint
• Scaffold
• DataType
• DisplayName
• DisplayFormat
• ReadOnly

A custom ModelValidatorProvider

Previous versions of FluentValidation had a custom IModelBinder implementation that allowed you to use FluentValidation to validate ASP.NET MVC action parameters. This will no longer be necessary in v1.2 as ASP.NET MVC 2’s ModelValidatorProvider infrastructure means FluentValidation can now be plugged in to MVC’s DefaultModelBinder:

public class MvcApplication : HttpApplication {
   public void Application_Start() {
      RegisterRoutes(RouteTable.Routes);
 
      ModelValidatorProviders.Providers.Add(new FluentValidationModelValidatorProvider(new AttributedValidatorFactory()));
   }
}

Note that the FluentValidationModelValidatorProvider will only support server-side validation, not client-side validation. FluentValidation’s validation mechanism is not compatible with how ASP.NET MVC 2 generates clientside validation rules.

Customisable Validator Cascade Mode

The validator cascade mode will be customisable in v1.2. Currently, if you have multiple validators defined on a single property then all of those validators will be executed even if the first one fails. This can be changed by calling the Cascade method:

RuleFor(x => x.Surname)
  .Cascade().StopOnFirstFailure()
  .NotNull()
  .Length(1, 250);

In this case, the Length validator would not be run on the Surname property if the NotNull validator fails.

This will also be customisable globally by setting the static property ValidatorOptions.CascadeMode.

I hope to release a first beta of v1.2 in the next couple of weeks. The final release should coincide with the release of ASP.NET MVC 2.