• Part 1 – Introduction
• Part 2 – New Syntax
• Part 3 – GridModels and GridRenderes
• Part 4 – Limitations of the WebFormsViewEngine
• Part 5 – The Action Syntax
• Part 6 – Sorting
• Part 7 – Auto-generated columns

The MvcContrib grid provides a way to automatically generate columns based on the public properties of an object. This is particularly useful when you are using a dedicated presentation model where the object properties map directly to the columns that you want to display.

To make use of this feature, you can call the AutoGenerateColumns method in the Grid declaration:

<%= Html.Grid(Model).AutoGenerateColumns() %>

By default, this will generate one column per public property and the name of the property will be used as the column heading (although PascalCased properties will have spaces inserted, eg “DateOfBirth” would be rendered as “Date Of Birth”).

This output can be customised by making use of MVC2’s ModelMetadata.

Out of the box, MVC2 uses the System.ComponentModel.DataAnnotations attributes to obtain metadata about a particular type (although you can also use other frameworks). The following attributes can be used to customise the auto-generated columns:

• ScaffoldColumn – can be used to prevent a property from being rendered as a grid column
• DisplayName – can be used to provide a custom column heading
• DisplayFormat – can be used to specify a custom display format

Additional columns not on your presentation model can also be added by making a call to the normal Columns method after the call to AutoGenerateColumns. For example, imagine we have a CustomerPresentationModel:

public class CustomerPresentationModel {
 
   [ScaffoldColumn(false)]
   public int CustomerId { get; set; }
 
   public string Name { get; set; }
   public DateTime DateOfBirth { get; set; }
}

If a collection of these objects is passed to the Grid method, then two columns will be auto-generated – one for Name and one for DateOfBirth (CustomerId is excluded because it is decorated with ScaffoldColumn(false))

If we also want to add an “Edit” link for the customer, then we could add an additional column:

<%= Html.Grid(Model).AutoGenerateColumns().Columns(extraColumns => {
        extraColumns.For(x => Html.ActionLink("Edit Customer", "Edit", new{ id = x.CustomerId });
}) %>

The additional column contains a link to the edit page for each customer. Note that while columns are automatically HTML-encoded, the grid will detect that ActionLink returns an instance of MvcHtmlString and therefore won’t encode this particular column.

Additional columns can also be re-ordered. For example, if we wanted our “Edit” link to appear before the Name/DateOfBirth then the InsertAt method could be used:

<%= Html.Grid(Model).AutoGenerateColumns().Columns(extraColumns => {
        extraColumns.For(x => Html.ActionLink("Edit Customer", "Edit", new{ id = x.CustomerId })
            .InsertAt(0);
}) %>

Note that the InsertAt method is not contained in the latest MvcContrib release – you’ll need to build from source to get this.

I’ve also started to put together some documentation for the grid on the MvcContrib wiki.

• Part 1 – Introduction
• Part 2 – New Syntax
• Part 3 – GridModels and GridRenderes
• Part 4 – Limitations of the WebFormsViewEngine
• Part 5 – The Action Syntax
• Part 6 – Sorting
• Part 7 – Auto-generated columns

I recently added single-column sorting support to the MvcContrib grid. This can be turned on by calling the “Sort” method on a grid declaration and accepting a parameter of type GridSortOptions in your controller actions.

Controller:

public ActionResult Sorting(GridSortOptions sort) 
{
  ViewData["sort"] = sort;
  var people = _peopleFactory.CreatePeople();
 
  if(!string.IsNullOrEmpty(sort.Column)) {
    people = people.OrderBy(sort.Column, sort.Direction);
  }
 
  return View(people);
}

View:

<%= Html.Grid(Model)
  .Sort(ViewData["sort"] as GridSortOptions)
  .Columns(column => {
      column.For(x => x.Id).Named("Person ID");
      column.For(x => x.Name);
      column.For(x => x.Gender);
      column.For(x => x.DateOfBirth).Format("{0:d}");
    }) %>

By calling the “Sort” method, this tells the grid that sorting should be enabled. This will generate sorting links for each column heading (note that currently sorting is enabled for all columns – there is no way to enable it for individual columns only. I’ll change this in a future release)

These sorting links will add two additional parameters to the querystring: Column and Direction. These can be handled in your controller action by taking as a parameter an object of type GridSortOptions.

Using this object, you can then sort your data using whatever mechanism you choose. Out of the box, MvcContrib provides an overload for the “OrderBy” extension method that takes a property name and a direction and delegates the sorting to IQueryable. However, use of this extension method is entirely optional.

This also works with the grid’s paging support, so if you want your data to be both paged and sorted then you can make a call to AsPagination (or by using a custom IPagination provider) after the call to OrderBy:

public ActionResult SortingAndPaging(int? page, GridSortOptions sort) 
{
  ViewData["sort"] = sort;
  var people = _peopleFactory.CreatePeople();
 
  if (!string.IsNullOrEmpty(sort.Column)) {
    people = people.OrderBy(sort.Column, sort.Direction);
  }
 
  people = people.AsPagination(page ?? 1, 10);
 
  return View(people);
}

…and the results will be as expected.

When a column is sorted, the CSS classes of “sort_asc” or “sort_desc” will be applied to the relevant <th> element, so you can style the column headings (for example, by adding up/down arrows).

In the video I cover some of the basics of using FluentValidation including:

• How to create a validator class
• Using templated error messages
• Writing custom validation rules
• Unit testing validators

After this, I demonstrate how you can use FluentValidation with ASP.NET MVC2 to perform automatic validation when using Model Binding, clientside validation and using FluentValidation to generate metadata.

The code for the presentation can be downloaded from here.

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.

• 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");
}

One of the new features in ASP.NET MVC 2 is the ability the ability to define multiple validation providers. These are used by the DefaultModelBinder to automatically validate your model objects when they are passed to action parameters.

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.

The Grid API allows you to define HTML attributes for a table by chaining a call to the ‘Attributes’ method as part of a grid definition:

<%= Html.Grid(Model.People).Columns(column => {
     		column.For(x => x.Id);
     		column.For(x => x.Name);
     		column.For(x => x.DateOfBirth);
})
.Attributes(style => "width:100%", cellpadding => 0)
 %>

This makes use of the MvcContrib.Hash class to construct an IDictionary from lambda expressions. So the following Hash definiton…:

var hash = new Hash(foo => "bar", baz => "blah");

…is the equivalent of:

var hash = new Dictionary<string, object> 
{
   { "foo", "bar" },
   { "baz", "blah" }
};

Internally, this is achieved by using a technique I first saw on Alex Henderson’s blog. By taking an array of delegates, it is possible to capture the compile-time variable names used by the lambda expressions and use them as keys for the dictionary.

The responses to this approach have been quite polarized. There has been lots of positive feedback on twitter…

“@JeremySkinner I like it, no problem for me, infact I’ll apply this technique where ever I can from now one forward ” (from Mark Nijhof)

“@JeremySkinner the lambda abuse is awesome, very ruby symbols like, and pushing the language envelope.” (from Adam Tybor)

…and also in the blogosphere (eg here and here) as well as on the StackOverflow post.

There has also been a lot of negative feedback:

“I hardly ever came across this kind of usage. I think it’s inappropriate”

“I find that odd not so much because of the name, but because the lambda is unnecessary; it could use an anonymous-type and be more flexible”

“This is horrible on more than one level. And no, this is nothing like Ruby its an abuse of C# and .Net. ”

“It’s counter-intuitive, there is no way of just looking at the code to figure out what it does.”

Interestingly, some of the most negative comments were from Eric Lippert on the C# compiler team:

“This is horrid in so many ways.”

“I just asked Anders (and the rest of the design team) what they thought. Let’s just say the results would not be printable in a family-friendly newspaper”

I thought Eric’s response was possibly a little harsh, but wanted to try and address and explain some of the issues here:

Issue #1: This is not interop friendly!

One of the issues raised was that this is not interop friendly. If, for example, you wanted to build a grid using F# (or possibly another CLR language) then this approach would not work as it is dependent on the C# compiler. This is a good point and is very true.

The thing I want to point out here is that the syntax is completely optional. This particular overload for the ‘Attributes’ method on the grid is an extension method for convenience when using C#. The main implementation for this method takes an IDictionary. If you don’t like the abusive-lambda approach (or you can’t use it from another language) then you can use the ‘regular’ overload instead:

.Attributes(new Dictionary<string, object> { { "style", "width:100%" }, { "cellpadding", 0 } })

The abusive-lambdas are merely a preference – I happen to like it as it saves me some keystrokes. If you don’t like it, don’t use it.

Issue #2: This is unintuitive and not intellisense-friendly

From a readability perspective, I do not agree that this is unintuitive. If you saw “Attributes(style => “width:100%”, cellpadding => 0)” in a grid definition then I think it’s pretty obvious what’s going on. It even looks like HTML attributes (kinda).

From an Intellisense perspective, I completely agree. If you see the following method signature, it is not immediately obvious what’s going on:

public static IGridWithOptions<T> Attributes<T>(this IGridWithOptions<T> grid, params Func<object, object>[] hash)

But hold on a second…let’s compare this to the approach that the ASP.NET MVC Framework uses for all its built-in HTML helpers:

public static MvcHtmlString TextBox(this HtmlHelper htmlHelper, string name, object value, object htmlAttributes)

Notice that “object htmlAttributes” at the end? That allows you to specify an anonymous type containing HTML attributes:

<%= Html.TextBox("foo", "bar", new{ style = "width:100%", @class="foo" })

This is just as opaque as using abusive lambdas. In fact, I’d aruge that it’s *more* opaque because the htmlAttributes parameter is defined as type object. This means you could accidentally pass *anything* in this parameter (eg a string) and the compiler would not complain. I have done this on many occasions and I find it very frustrating. At least with a parameter of type Func<object, object>[] you can’t accidentally pass in a string. (Much like the MvcContrib approach, ASP.NET MVC’s helpers also have overloads that take an IDictionary if you prefer).

Issue #3: You can achieve the same result with an anonymous type:

I don’t believe that the Hash is really any worse than the anonymous type. In fact, in some ways I think the use of an anonymous type is worse (see my point above regarding opacity)

Issue #4: Performance implications!

There seems to be some misunderstanding around the use of the lambda syntax. On the one hand you can use a lambda to define an expression tree which can then be parsed (this is how LINQ to SQL works – the expression tree is then converted to SQL). These expressions can then be compiled to a delegate and invoked which is an expensive operation. However, lambdas can also be used for anonymous methods. This is essentially syntactic sugar over a standard .NET delegate and is an improvement over C# 2′s anonymous delegate syntax.

The MvcContrib uses the latter approach to do its work. This way, there is no overhead for compiling the expressions. In fact, there is very little overhead versus using the standard Dictionary.Add method. Alex Henderson talks more about the different approaches for doing this on his blog, but these were the results of his benchmark for 10000 calls:

• Using Dictionary.Add: 10.0144ms
• Using lambdas with expression compilation: 9713.968ms (240.3456ms with constants)
• Using lambdas as delegates: 30.0432ms

Issue #5: Why not use method chaining?

One suggestion was to chain multiple calls to ‘Attribute’:

.Attribute("style", "width:100%").Attribute("cellpadding", "0")

This definitely works, but the whole reason why I decided to use the Hash was because I want to mimimize the amount of typing (my fingers tire easily) and making multiple calls to ‘Attribute’ is rather verbose.

And finally…

In the end, this is really just down to personal preference:

• I do not like C#’s dictionary initializers – I think they’re too verbose
• I do not like the use of anonymous types as dictionaries as they require you to take parameters of type “object”

The Abusive Lambda Pattern (I think that’s what I’ll call this) is just something I happen to like, but if you don’t like it then you certainly don’t have to use it.

Perhaps Eric and the C# team would like to give us a more succinct collection initializer for Dictionaries in C#5?