Since I wrote the first part of the article, Steve Sanderson adopted my idea of automatic client-side validation and baked a similar feature right into the latest version of xVal.

One important thing is still missing though: What do you do when validation depends on server-side resources but also involves several different form fields? For example, let’s assume you were implementing a form for your website users to update their contact information.

Figure 1 – Example update form

The form is very similar to the signup form from the last part of this article. However this time instead of adding new data to the database, the user needs to update his e-mail address. Validation still has to check that the e-mail address entered does not already exist yet. However, this time it should ignore the current user’s e-mail address.

For example, if the current user’s e-mail address is adrian@lobstersoft.com, then we still want to accept this as valid input. But if he enters “john@doe.com” and that e-mail address is already taken, we want client-side validation to fail.

And all of this should of course work automatically on both the server and client side simply by providing a server-side validation rule and attaching it the Viewmodel:

Listing 1 – ViewModel with client/server side enabled entity validation attribute

    [EmailUnique]
    public class UserModel
    {
        public int ID{ get; set;}

        [Required(ErrorMessage = "E-mail address is missing.")]
        [RegularExpression(EmailRegEx, ErrorMessage = "Invalid e-mail address.")]
        [EmailUnique]
        public string Email { get; set; }

        public class EmailUniqueAttribute : RemoteEntityValidator
        {
            public EmailUniqueAttribute()
                : base(new string[] { "Email", "ID" }, typeof(User))
            {
                ErrorMessage = "Someone else has already signed up with this e-mail address.";
            }

            protected override bool EntityValid(object value)
            {
                User entity = (User)value;
	      //make sure there is no user with a different ID but same e-mail address
                return !new FakeUsersRepository().LoadAll().Any(u => u.ID != entity.ID && u.Email == entity.Email);
            }
        }

	// Other UserModel properties and validation attributes...
}

Behind the scenes

Validation of the e-mail input on this form depends on two variables: The user’s e-mail address and his user ID.

Therefore we need to:

1. Store the user id as a hidden form input field
2. Provide a client-side Javascript function that creates a remote validation rule that submits all relevant form input fields for the particular validation rule to the server.
3. Provide a server-side action method that triggers the validation attribute’s IsValid method and returns the result to the client-side remote validator.

The approach is quite similar to remote property validation, except that multiple form input fields have to be provided to the server, but there are also a few other other minor differences. For example the client-side remote validation rules must also be re-validate when one of the other form input elements that validation depends on is changed.

But the good news is that all of this can be still solved in a generic way so that you can get away just by coding your server-side data annotation validation attributes – Very similar to the technique shown in the first part of this article.

Using the RemoteEntityValidator

For using the code provided with this article in your own project, proceed as follows:

1. Add Xval, jquery.validate, DataAnnotationModelBinder and the code provided in this article’s demo project to your project as shown in the first part of this article.
2. Next, whenever you need to write a validation attribute that depends on multiple properties of your view model, derive your validation attribute from RemoteEntityValidator as shown in Listing 1.

These are the differences you have to mind in comparison to the RemotePropertyValidator from the first part of the article:

• The RemoteEntityValidator’s constructor takes one more variable than the RemotePropertyValidator: A string array of all property names in the ViewModel which are relevant for running the validation rule. I guess this could also be done in a more type-safe way by using Linq expressions, but I chose strings for the sake of a simpler syntax, especially when handling many different form fields.

• Note that even though the RemoteEntityValidator depends on several model properties, you must not apply it to all relevant properties in your model. Just apply it to the ViewModel entity and the property that corresponds to the html input element where you want the client-side validation error to appear. However, you do have to apply it both to the ViewModel property AND to the ViewModel class. The property-level attribute is needed for the triggering client side validation when the input element is changed, and the entity-level attribute is needed for server side validation to work.

• Your html form needs to have an ID attribute. It could be done without, but in my project this led to some problems with client-side validation when the form was reloaded via ajax. That’s why I changed the client-side code for retrieving form input values to something more stable since posting the first part of this article.

Download the demo project

Conclusion

You have learned how to implement client- and server-side validation in a completely generic, model-oriented way. This part of the article completed the technique shown before with validation attributes that depend on several model properties.

In addition, there are some validation rules which cannot be checked completely on the client side, for example because the validation depends on information stored in the server database. For those rules you need to implement remote client-side form validation.

The xVal framework is great for automatic generation of client-side validation code for some of your server-side validation rules, but it does not support remote client-side validation.

This article shows a fully generic way to implement remote client-side form validation so that

• Validation rules remain solely in your ASP.NET MVC model
• You write each validation rule just once, and only in easily testable C# code. There is no JavaScript or other client-side counterpart .
• There is no need to branch or otherwise modify xVal or jquery.validate
• All you have to do for each new remote form validation rule is to derive from the base class shown in this article.

I’ll describe how to implement this in detail. I’ve also uploaded a demo project showing how this works in action.

A brief example

Let’s assume you are implementing a website signup form. For the sake of simplicity, lets limit the form to asking for an e-mail address and a password.

Figure 1 – Example signup form

You want to implement the signup form with both client and server side validation. For the e-mail field, let’s enforce the following validation rules:

1. Email address is not missing
2. Email address looks valid
3. There is no other user with the same e-mail address in your database.

Rules 1 and 2 can easily be checked on the client side. However, rule 3 can only be done with remote validation: Your client-side validation script needs to connect to your web server and ask if the e-mail address is already taken.

In our example, the only user already in the databse shall be adrian@lobstersoft.com. As soon as someone enters this e-mail address in the form and hits tab, return, or the Create button, an error message should appear before the form has even been posted:

Figure 2 – Error messages should appear before the form has even been posted

Listing 1 shows the entire validation logic necessary for both client and server side validation:

Listing 1 – Signup form client- and server-side validation rules

using System.ComponentModel.DataAnnotations;

namespace RemoteValidation.Models
{
    public class User
    {
        [Required(ErrorMessage = "E-mail address is missing.")]
        [RegularExpression(EmailRegEx, ErrorMessage = "Invalid e-mail address.")]
        [IsNew(ErrorMessage = "Someone has already signed up with this e-mail address.")]
        public string Email { get; set; }

        [Required(ErrorMessage = "Password is missing.")]
        public string Password { get; set; }

        public class IsNewAttribute : RemotePropertyValidator
        {
            protected override bool PropertyValid(object value)
            {
                return (string)value != "adrian@lobstersoft.com";
            }
        }

        private const string EmailRegEx = @"^(([^<>()[\]\\.,;:\s@\""]+"
                                  + @"(\.[^<>()[\]\\.,;:\s@\""]+)*)|(\"".+\""))@"
                                  + @"((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"
                                  + @"\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+"
                                  + @"[a-zA-Z]{2,}))$";
    }
}

The SignUp action methods should also be easy to implement since the controller does not need to know anything about our validation rules.

Listing 2 – Signup form action methods

         //
        // GET: /Users/SignUp
        public ActionResult SignUp()
        {
            return View(new User());
        }

        //
        // POST: /Users/SignUp
        [AcceptVerbs(HttpVerbs.Post)]
        public ActionResult SignUp(User model)
        {
            if (!ModelState.IsValid)
            {
                return View(model);
            }

            //Add User to database and start spamming daemon here

            return RedirectToAction("SignUpComplete");
        }

Lastly, here’s how the view above is implemented.

Listing 3 – Signup form view implementation

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<RemoteValidation.Models.User>" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
    SignUp
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
    <h2>
        SignUp</h2>
    <%= Html.ValidationSummary("SignUp was unsuccessful. Please correct the errors and try again.") %>
    <% using (Html.BeginForm())
       {%>
    <fieldset>
        <legend>Fields</legend>
        <p>
            <label for="Email">
                Enter your e-mail address:</label>
            <%= Html.TextBox("Email")%>
            <%= Html.ValidationMessage("Email", "*")%>
        </p>
        <p>
            <label for="Password">
                Enter a password:</label>
            <%= Html.Password("Password")%>
            <%= Html.ValidationMessage("Password", "*")%>
        </p>
        <p>
            Hint: To see that remote validation works, try signing up as "adrian@lobstersoft.com".
        </p>
        <p>
            <input type="submit" value="Create" />
        </p>
    </fieldset>
    <% } %>

    <%= Html.ClientSideValidation<RemoteValidation.Models.User>()%>
</asp:Content>

Note that the View does not contain any JavaScript or other means to specify client-side validation rules. Everything is done transparently and automatically behind the scenes.

Prerequisites

In order for this to work, you need to set up a few things first:

1. Data Annotation validation attributes for server-side validation. IMO this is the best way to handle server-side validation anyway, even if you are not using client-side validation at all.

   Brad Wilson has written a great blog article on how to use DataAnnotations in ASP.NET MVC.

   Note that there is a bug in DataAnnotationModelBinder which might lead to NullReferenceExceptions when using custom ViewModels. This does not become apparent in our demo project, but if you should encounter this problem, you can find a fix in this StackOverflow posting.

2. Download and reference jquery.validate in your Master Page.
3. Download and reference xVal version 0.8 or later in your project. xVal is a great framework for easy implementation of client-side validation in ASP.NET MVC. It transforms standard server-side validation rules into client-side validation rules recognized by jquery.validate.

   Steve Sanderson describes how to set it up and use in this blog article.

Once you get this far, you can implement rules 1 and 2 from our example. You could also implement rule 3, although you’d have to derive it from System.ComponentModel.DataAnnotations.ValidationAttribute, so there would’t be any client-side validation for that.

Implementing generic client-side Remote Validation

While rules 1 and 2 are automagically enforced by xVal on both the client and server side, rule 3 is only checked when the user posts the form. That’s because xVal does not know what to do with our custom rule. It just looks for standard validation rules like Required, StringLength or RegularExpression and ignores everything else.

Enforcing rule 3 on the client side as well without incurring any additional effort is where the technique I would like to present comes into play.

The first step is not to derive your custom validation rule from ValidationAttribute, but from the RemotePropertyValidator class I implemented. This is already depicted in Listing 1 above.

RemotePropertyValidator is in turn derived from ValidationAttribute, but it also implements xVal’s ICustomRule interface. This allows it to specify a JavaScript function that should be executed in order to check if the given property is valid on the client side.

RemotePropertyValidator tells xVal to execute the JavaScript function “RemotePropertyValidation”. The parameters for this function should be the type of your derived custom validator and the Error message you specified:

Listing 4 – RemotePropertyValidation class

   public abstract class RemotePropertyValidator : ValidationAttribute, ICustomRule
    {
        public CustomRule ToCustomRule()
        {
            return new CustomRule(
                "RemotePropertyValidation", // JavaScript function name
                new
                    {
                        validator = ToString(),
                        errorMessage = base.ErrorMessage,
                    }, // Params for JavaScript function

                base.ErrorMessage
                );
        }
    }

You might be wondering why I am checking for empty strings / null in Listing 4. That’s because of differences between how xVal / jquery.validate work on the client side and how the DataAnnotationsModelRunner is implemented on the server side: While it is possible to implicitly implement a Required validator by deriving from ValidationAttribute on the server side, it is not possible to do this with ICustomRule descendents on the client. So I am checking for empty strings / null to avoid inconsistent behaviour.

The ClientSideRegEx property can be set to a regular expression that will be executed on the client before the remote validation is done. You can use it to avoid unnecessary calls to your RemoteValidation controller.

Now, when the user starts typing something in the e-mail field, the browser will execute the JavaScript function “RemotePropertyValidation”. Note that this function will receive your derived server-side validator’s object type and your validator’s error message as parameters.

Next, we need to implement a generic RemotePropertyValidation function. In this function we can create a “remote” validation rule as supported by jquery.validate and attach it to the Email e-mail input field’s rules collection:

Listing 5 – Generic client-side remote validation function

function RemotePropertyValidation(value, element, params) {
    var wrappedElement = $(element);
    if (wrappedElement.rules()["remote"] === undefined) {
        //add optional regEx validator to minimize ajax requests
        if (params.regEx !== null && wrappedElement.rules()["xVal_regex"] === undefined) {
            wrappedElement.rules("add", {
                xVal_regex: [params.regEx],
                messages: {
                    xVal_regex: params.errorMessage
                }
            });
        }
        var remoteRule =
        //add a new remote validation rule
        wrappedElement.rules("add", {
            remote: {
                url: "/RemoteValidation/Property",
                data: {
                    value: new CreateInputValueAccessor(wrappedElement.attr("name")),
                    validator: params.validator
                }
            },
            messages: {
                remote: params.errorMessage
            }
        });

        //validate element again to trigger the new rule(s)
        $("form").validate().element(wrappedElement);
    }
    return true;
}

function CreateInputValueAccessor(inputName) {
    return function() {
        return $("[name=" + inputName + "]").val();
    };
}

The RemotePropertyValidation () function should be referenced in your Master page. Now the first time a user enters something in the Email field , jquery.validate will first validate it using the Required and the Regex rule. If both rules are satisfied, it will check if the e-mail address is already taken with the validation rule that RemotePropertyValidation() inserted on the fly. This will fetch the following URL and parse the JSON reply as validation result.:

http:///RemoteValidation/Property?value=&validator=RemoteValidtion.Models.User.IsNew

Now we just need to implement a RemoteValidation that construct an appropriate validator object (note that this is provided in “validator” request parameter), let it validate the user input and return the validation result as JSON:

Listing 6 – RemoteValidation controller

using System;
using System.Reflection;
using System.Web.Mvc;
using RemoteValidation.Models;

namespace RemoteValidation.Controllers
{
    public class RemoteValidationController : Controller
    {
        //
        // GET: /RemoteValidation/Property
        public JsonResult Property()
        {
            Type validatorType = Type.GetType(Request["validator"], true);
            var validator = (RemotePropertyValidator) Activator.CreateInstance(validatorType);
            return Json(validator.IsValid(Request["value"]));
        }
    }
}

And that’s it! Now that you have the JavaScript RemotePropertyValidation function and the remote validation controller in place, all you need to do for new custom validation rules is to derive them from RemotePropertyValidator. This ensures that your validation rules are are automatically enforced on both the server and the client.

For example, all you’d need to implement for server AND remote client-side validation of password strength is this:

Listing 7 – Complete implementation of an additional client- and server-side Validator

 public class IsSafePasswordAttribute : RemotePropertyValidator
        {

            public IsSafePasswordAttribute()
            {
                //perform some simple password strength check with a regular expression
                //on the client side first
                ClientSideRegEx = ".{8,20}";
            }

            protected override bool PropertyValid(object value)
            {
                //Insert more elaborate server-side / remote client side password checking
                // logic and return result here...
            }
        }

Caveats

There are a few things you should keep in mind when using this technique:

• You can’t implicitly implement a Required validator using this technique, so if a property is not optional, you must always decorate it with a Required validator apart from of your own RemotePropertyValidator descendant. It wouldn’t really make sense to implement a Required validator this way anyway. Please see the Implementation section above if you are interested in the reason for this.
• You can only apply one remote validation rule per form field. This is a limitation of jquery.validate, and it makes sense not to have more than one remote validation rule anyway since you want to minimize the amount of server postbacks as much as possible. If you need to remotely check two different rules on the same property, you can always write a new rule which incorporates both checks, so the only problem is finding an error message that fits both validation rules.
• This approach only works for Validation Attributes applied to properties, not to entire business entities. I’ll discuss a similar approach for validating entire business entities in the second part of this article.

Download the finished demo project

Summary

Now you know how to implement remote client-side validation without writing any custom JavaScript code. I discussed how to implement all validation rules, even those that can only be checked on the server, on both the client AND server side in C# code only. I showed how you can do this without any additional effort when implementing new rules.

The only real limitation is that the business rule can check only a single property, not an entire business entity. Stay tuned for the second part of this article, where I’ll discuss how to circumvent this limitation in a similarly easy way.

Edit: The second part of this article has already been posted here.