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.

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.

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.

Be sure to check it out.

Quick recap: What is FluentValidation?

FluentValidation allows you to use a fluent interface and lambda expressions to define validation rules for your objects:

public class CustomerValidator: AbstractValidator<Customer> {
  public CustomerValidator() {
    RuleFor(customer => customer.Surname).NotEmpty();
    RuleFor(customer => customer.Forename).NotEmpty().WithMessage("Please specify a first name");
    RuleFor(customer => customer.Discount).NotEqual(0).When(customer => customer.HasDiscount);
    RuleFor(customer => customer.Address).Length(20, 250);
    RuleFor(customer => customer.Postcode).Must(BeAValidPostcode).WithMessage("Please specify a valid postcode");
  }
 
  private bool BeAValidPostcode(string postcode) {
    // custom postcode validating logic goes here
  }
}

…which can then be executed against a particular instance of your class:

Customer customer = new Customer();
CustomerValidator validator = new CustomerValidator();
ValidationResult results = validator.Validate(customer);
 
bool validationSucceeded = results.IsValid;
IList<ValidationFailure> failures = results.Errors;

What’s new in version 1.1?

Quite a lot of FluentValidation has been re-written with the 1.1 release, but these are the changes most noticable to the end user:

Nested Validators

It is now possible to re-use validators. For example, if you have a Customer object that has a property of type Address, then you can declare an AddressValidator like this:

public class AddressValidator : AbstractValidator<Address> {
   public AddressValidator() {
        RuleFor(x => x.Property).NotNull().Length(1, 250);
        RuleFor(x => x.District).NotNull().Length(1, 250);
        RuleFor(x => x.Country)...
        //etc
   }
}

…and then your CustomerValidator can specify that the Address property should be validated using the AddressValidator:

public class CustomerValidator : AbstractValidator<Customer> {
    public CustomerValidator() {
       RuleFor(x => x.Surname).NotNull();
       RuleFor(x => x.Address).SetValidator(new AddressValidator()); 
    }
}

Additional Language Translations

Thanks to several user contributions, the default validation messages are now available in German, Spanish, French, Dutch and Portuguese in addition to English.

Chaining Validators

In version 1.0, if you wanted to specify multiple validation rules on a single property then you had to use the ‘And’ operator:

RuleFor(x => x.Name).NotNull().And.NotEqual("foo");

…but in v1.1 these can now be chained together directly:

RuleFor(x => x.Name).NotNull().NotEqual("foo");

IValidatorSelector

The new IValidatorSelector interface allows you to specify which validation rules should be executed when performing validation. I’m planning a more in-depth post on this in the future.

Message Formatting Placeholders

Custom validation messages can now use special placeholders, eg:

RuleFor(x => x.Surname).NotNull().WithMessage("You must enter a value for {PropertyName}!");

There’s a complete list of placeholders in the documentation. I plan to write a more detailed post about how to use custom placeholders in your own, custom validators in the future.

What’s coming in v1.2?

For version 1.2, I’m planning on incorporating Adam’s work on adding xVal integration for FluentValidation as well as adding a sample application.

In Eric’s example, he has a class called SampleModel whose properties are decorated by several attributes:

public class SampleModel
{
  public Guid Guid { get; set; }
 
  [Required]
   public string Name { get; set; }
 
  [Required]
  [Label("Number of Types")]
  [PartialView("RadioButtons")]
  public NumberOfTypeEnum EnumAsRadioButton { get; set; }
 
  public NumberOfTypeEnum Enum { get; set; }
 
  [Range(3, 15)]
  public int IntegerRangeValue { get; set; }
 
  [Example("mm/dd/yyyy hh:mm PM")]
  public DateTime TimeStamp { get; set; }
 
  [DataType(DataType.MultilineText)]
  public string Html { get; set; }
 
  public bool IsNeeded { get; set; }
}

These properties on this object are then rendered in the view by using the strongly-typed Input extension:

<%=Html.Input(c => c.Name)%>
<%=Html.Input(c => c.TimeStamp)%>
<%=Html.Input(c => c.Html)%>
...etc...

The attributes that decorate the properties drive the UI, so for example decorating the Html property with [DataType(DataType.MultilineText)] would cause a multi-line textbox to be rendered.

Rather than using attributes, my aim was to configure the InputBuilders by storing metadata alongside validation information in a Validator class.

Out of the box, FluentValidation supports several validator types. Some of these map nicely to the DataAnnotations attributes used by the SampleModel. For example, the [Required] attribute maps nicely to the NotNull and NotEmpty validators, and the [Range] attribute works nicely with the GreaterThan/LessThan validators:

public class SampleModelValidator : AbstractValidator<SampleModel> {
  public SampleModelValidator() {
    RuleFor(x => x.Name).NotEmpty();
 
    RuleFor(x => x.IntegerRangeValue)
      .GreaterThanOrEqualTo(3)
      .LessThanOrEqualTo(15);
  }
}

However, there are no equivalents for the metadata attributes such as [PartialView], [Example] or [DataType], but these can easily be built by constructing some ‘fake’ validators (these validators won’t actually perform any validation – they will simply hold metadata).

For example, to build an equivalent for the DataTypeAttribute, we can create a property validator like this:

public interface IDataTypeMetaData {
	DataType DataType { get; }
}
 
public class DataTypeValidator<T, TProperty> : IPropertyValidator<T, TProperty>, IDataTypeMetaData {
	private DataType datatype;
 
	public DataTypeValidator(DataType datatype) {
		this.datatype = datatype;
	}
 
	public PropertyValidatorResult Validate(PropertyValidatorContext<T, TProperty> context) {
		return PropertyValidatorResult.Success();
	}
 
	public DataType DataType {
		get { return datatype; }
	}
}

Note that we declare both a validator to hold the DataType information and also a non-generic interface (which we’ll use later to obtain the metadata). The Validate method is a no-op, always reporting success (as we don’t actually want to perform any validation).

Next, we can declare an extension method that allows this to be used from within our SampleModelValidator:

public static class ValidatorExtensions {
	public static IRuleBuilderOptions<T, TProperty> DataType<T, TProperty>(this IRuleBuilder<T, TProperty> ruleBuilder, DataType dataType) {
		return ruleBuilder.SetValidator(new DataTypeValidator<T, TProperty>(dataType));
	}
}

After using this approach to create equivalents for all the other metadata attributes, our SampleModelValidator now looks like this:

public class SampleModelValidator : AbstractValidator<SampleModel> {
	public SampleModelValidator() {
		RuleFor(x => x.Name).NotEmpty();
 
		RuleFor(x => x.EnumAsRadioButton)
			.NotNull()
			.RenderUsing("RadioButtons")
			.WithName("Number of Types");
 
		RuleFor(x => x.IntegerRangeValue)
			.GreaterThanOrEqualTo(3)
			.LessThanOrEqualTo(15);
 
		RuleFor(x => x.TimeStamp).Example("mm/dd/yyyy hh:mm PM");
 
		RuleFor(x => x.Html).DataType(DataType.MultilineText);
	}
}

The next stage is to create a custom ValidatorDescriptor. The default ValidatorDescriptor doesn’t do very much so we’ll need to inherit from it and create some additional methods to retrieve the information needed by the InputBuilder:

using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using FluentValidation;
using FluentValidation.Internal;
using FluentValidation.Validators;
 
public interface ICustomValidatorDescriptor {
	string GetExample(PropertyInfo prop);
	string GetLabel(PropertyInfo prop);
	string GetPartialName(PropertyInfo prop);
	bool GetIsRequired(PropertyInfo prop);
}
 
public class CustomValidatorDescriptor<T> : ValidatorDescriptor<T>, ICustomValidatorDescriptor {
	public CustomValidatorDescriptor(IEnumerable<IValidationRule<T>> ruleBuilders) : base(ruleBuilders) {
	}
 
 
	public string GetExample(PropertyInfo prop) {
		return Rules.OfType<ISimplePropertyRule<T>>()
		       	.Where(x => x.Member == prop)
		       	.Select(x => x.Validator)
		       	.OfType<IExampleMetaData>()
		       	.Select(x => x.Example).FirstOrDefault() ?? string.Empty;
	}
 
	public string GetLabel(PropertyInfo prop) {
		return Rules.OfType<IPropertyRule<T>>()
				.Where(x => x.Member == prop)
				.Select(x => x.PropertyDescription).FirstOrDefault();
	}
 
	public string GetPartialName(PropertyInfo prop) {
		return Rules.OfType<ISimplePropertyRule<T>>()
				.Where(x => x.Member == prop)
				.Select(x => x.Validator)
				.OfType<IRenderUsingMetaData>()
				.Select(x => x.ViewName).FirstOrDefault();
	}
 
	public bool GetIsRequired(PropertyInfo prop) {
		return Rules.OfType<ISimplePropertyRule<T>>()
			.Where(x => x.Member == prop)
			.Select(x => x.Validator)
			.Where(x => x is INotNullValidator || x is INotEmptyValidator)
			.Any();
	}
}

The ValidatorDescriptor accepts in its constructor a collection of IValidationRule objects that represent the rules configured in the SampleModelValidator. Using some Linq magic we can retrieve the metadata information that we stored inside the validation rules. We also have to override the CreateDescriptor method in our SampleModelValidator to return an instance of our custom ValidatorDescriptor, rather than the default:

public override IValidatorDescriptor<SampleModel> CreateDescriptor() {
	return new CustomValidatorDescriptor<SampleModel>(this);
}

The next stage is to override the InputBuilder’s default conventions so that it will use our SampleModelValidator to obtain its metadata. To do this, we create a FluentValidationConventions class that accepts a ValidatorFactory in its constructor and contains methods that delegate to our CustomValidatorDescriptor:

public class FluentValidationConventions {
	private IValidatorFactory validatorFactory;
 
	public FluentValidationConventions(IValidatorFactory factory) {
		this.validatorFactory = factory;
	}
 
	private ICustomValidatorDescriptor GetDescriptor(Type type) {
		var validator = validatorFactory.GetValidator(type);
		return (ICustomValidatorDescriptor) validator.CreateDescriptor();
	}
 
	public string ExampleConvention(PropertyInfo prop) {
		return GetDescriptor(prop.ReflectedType).GetExample(prop);
	}
 
	public string LabelConvention(PropertyInfo prop) {
		return GetDescriptor(prop.ReflectedType).GetLabel(prop) ?? DefaultConventions.LabelForProperty(prop);
	}
 
	public string PartialNameConvention(PropertyInfo prop) {
		return GetDescriptor(prop.ReflectedType).GetPartialName(prop) ?? DefaultConventions.PartialName(prop);
	}
 
	public bool RequiredConvention(PropertyInfo prop) {
		return GetDescriptor(prop.ReflectedType).GetIsRequired(prop);
	}
}

Note that I used a very simple implementation of ValidatorFactory for this example that wraps a Dictionary. A real ValidatorFactory would probably wrap an IoC container or a Service Locator:

public class SampleValidatorFactory : IValidatorFactory {
	static Dictionary<Type, IValidator> validators = new Dictionary<Type, IValidator>() {
		{ typeof(SampleModel), new SampleModelValidator() }
	};
 
	public IValidator<T> GetValidator<T>() {
		return (IValidator<T>) GetValidator(typeof (T));
	}
 
	public IValidator GetValidator(Type type) {
		IValidator validator;
		if (validators.TryGetValue(type, out validator)) {
			return validator;
		}
		return null;
	}
}

In our global.asax, we can then replace the InputBuilder’s default conventions with our custom conventions:

protected void Application_Start()
{
	RegisterRoutes(RouteTable.Routes);
	InputBuilder.InputBuilder.BootStrap();
	SetupFluentValidationConventions();
}
 
private void SetupFluentValidationConventions() {
	var conventions = new FluentValidationConventions(new SampleValidatorFactory());
 
	ModelPropertyFactory.ExampleForPropertyConvention = conventions.ExampleConvention;
	ModelPropertyFactory.LabelForPropertyConvention = conventions.LabelConvention;
	ModelPropertyFactory.PartialNameConvention = conventions.PartialNameConvention; 
	ModelPropertyFactory.PropertyIsRequiredConvention = conventions.RequiredConvention; 
}

…and that’s it. The InputBuilder will now get all its metadata from our Validator class rather than from attributes. If you want to play with the source code for this example it’s available in my svn repository at https://www.jeremyskinner.co.uk/svn/public/trunk/FluentValidationInputBuilders (username ‘guest’) on GitHub and can be downloaded from here.

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