OK.  So I added some server side rule checking as a backup to the client side stuff.  In order to test this out, I had to turn off client side validation.  Right now it only returns a list of validation error messages, but I have some plans for that mechanism.  The controller method that handles the form post now looks like this:

 

	[AcceptVerbs("POST")] public ActionResult Edit(int id, Customer customer) { customer.ID = id; if (!Model.IsValid(customer)) { ViewData["errormessages"] = Model.GetErrorMessages(customer); return View(customer); } RepoFactory.Get<Customer>().Save(customer); return this.RedirectToAction("index"); }
1 2 3 4 5 6 7 8 9 10 11 12 13

The only change i made to the Customer class so far was that I added a custom model binder attribute to the customer.  That attribute looks like this:

	public class CustomerBinder : IModelBinder { public object GetValue(ControllerContext controllerContext, string modelName, Type modelType, ModelStateDictionary modelState) { NameValueCollection form = controllerContext.HttpContext.Request.Form; return new Customer { FirstName = form["FirstName"], LastName = form["LastName"] }; } }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

And the customer class looks like this(i updated the validation attribute constructors to match the changes i made.

	[ModelBinder(typeof(CustomerBinder))] public class Customer : IModel { public int ID { get; set; } [ValidateLength(3, 30, "First name must be between 3 and 30 characters in length.", true)] public string FirstName { get; set; } [ValidateMaxLength(30, "Last name is required and cannot exceed 30 characters.", true)] public string LastName { get; set; } }
1 2 3 4 5 6 7 8 9 10 11 12 13

and the server side validation ends up rendering the following view(reminiscent of lammo validation summary in webforms):

This one bugs me.  Scott Guthrie has a huge post on some new form stuff that comes with preview 5.  Great info there.  However, looking at the validation examples, you can see that the validation depends on on checking business rules and throwing exceptions if any of the rules fail; then in the controller you catch a general System.Exception, update some stuff for the view, and return the same view.  Why is this bad?

Well, an exception didn't really occur, it was made up because of failing a known business rule.  So basically, now you're using the throwing of exceptions to guide your workflow which makes your code hard to test and hard to follow.  I wouldn't  normally comment on something like this, but I saw another example of this by Stephen Walther here. 

People, please don't throw exceptions in non-exceptional situations.

OK.  So why is it, that most of the validation examples I see for ASP.NET MVC always include allowing the user to submit potentially invalid form fields to the server?? 

If your validation "framework" requires you to submit a form to the server prior to being validated, then your framework sucks.  Period.  Definitely have the server side validation.  Server side validation exists to double check that you didn't fuck up and miss something on the front end with client side validation.

 I implemented a VERY lame outline of something that I would expect from a framework.  Simple attributes are applied to properties that are bound in the view.  My example expects that you are using jQuery.  This is not good. 

A validation framework that works on the client, should not care about it's implementation but should have a default implementation. So it shouldn't care if you're a jQuery fan, or prototype fan, or not a fan of javascript at all;it should establish some common methods that you are free to implement yourself.

If Microsoft were to implement a good validation framework, here's what I would require from them.  Zero installation.  Requiring that you install the Enterprise Library to get any sort of validation bennies is absurd, please stop doing this.

The framework would default to Microsoft's home grown javascript library, but with VERY little effort, could be switched out with prototype, jQuery, or any javascript framework you want.

Here's my scratch project trying to come up with a better validation framework.  It's tied to jQuery, which I don't like.  It looks for any element(i've only concentrated on an input element of type="text", so it doesn't do much) that contains a 'validate' attribute.  then inspects other css classes that have been tacked on that indicate some sort of validation to perform on the element.  I'm thinking of also sticking other attributes on the element when it's generated, not XHtml-ish, but oh well.

It's based on attributes that implement my IModelValidator interface which looks like this:

	public interface IModelValidator { bool Validate(object value); }
1 2 3 4

The ValidateRequiredAttribute tests to make sure a value exists and looks like this:

	public class ValidateRequiredAttribute : System.Attribute, IModelValidator { public bool Validate(object value) { if (value == null) return false; if (System.Convert.ToString(value).Length == 0) return false; return true; } }
1 2 3 4 5 6 7 8 9

ValidateMaxlengthAttribute checks to make sure the length of a value does not exceed a max value:

	public class ValidateMaxLengthAttribute : System.Attribute, IModelValidator { private int _maxLength = 0; public int MaxLength { get { return _maxLength; } } public ValidateMaxLengthAttribute(int maxLength) { _maxLength = maxLength; } public bool Validate(object value) { if (value == null) return false; return System.Convert.ToString(value).Length <= this._maxLength; } }
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Implementing the attributes on a model should look something like this:

	public class Customer : IModel { public int ID { get; set; } [ValidateRequired(), ValidateMaxLength(30)] public string FirstName { get; set; } [ValidateRequired(), ValidateMaxLength(30)] public string LastName { get; set; } }
1 2 3 4 5 6 7 8 9 10