Enterprise Library

Leverage EntLib Validation Application Block in MVC

Steve Michelotti — Tue, 17 Jun 2008 19:47:32 GMT

One of the areas of MVC that is still an open area in development is how best to handle UI validations. There are numerous approaches currently being examined.

The Enterprise Library's VAB is great because it allows you to specify all your validation logic in your business layer where it belongs rather than in your UI. Additionally, it comes with the PropertyProxyValidator to automatically display validation messages in the UI and avoid having to put hundreds of validators on a page. However, the PropertyProxyValidator is a traditional ASP.NET validator control and does not work in the MVC framework.

The good news here is that duplicating the functionality of the PropertyProxyValidator in the MVC framework is not difficult. Currently, the MVC framework comes with some built-in extension methods to enable the developer to easy create UI elements hanging off the HtmlHelper property. I've written a couple of similar extension methods following the same pattern that essentially produce the same output as the ProperyProxyValidator. This enables us to write UI code without cluttering our mark up with a ton of validator controls:

   1:  <%=Html.TextBox("FirstName", ViewData.Model.Contact.FirstName)%>

   2:  <%=Html.Validator("FirstName", ViewData.Model.ValidationResults)%>

Notice that a property called "ValidationResults" is being passed in to this Validator. When the form is submitted, it goes to a controller action (let's say "Save" for this example):

   1:  public ActionResult Save(int id)

   2:  {

   3:      Contact contact = new Contact();

   4:      contact.ContactID = id;

   5:      BindingHelperExtensions.UpdateFrom(contact, Request.Form);

6:

   7:      ValidationResults validationResults = Validation.Validate(contact);

   8:      if (validationResults.IsValid)

   9:      {

  10:          contactManager.SaveContact(contact);

  11:          return RedirectToAction(Views.Index);

  12:      }

  13:      else

  14:      {

  15:          ContactViewData contactViewData = new ContactViewData(contact);

  16:          contactViewData.ValidationResults = validationResults;

  17:          ViewData.Model = contactViewData;

  18:          return View(Views.EditContact);

  19:      }

  20:  }

So if the contact object in this example is valid, we save it to the database and proceed as normal to the next redirect action. However, if the contact is not valid, we redisplay the edit contact page again and this time we pass the ValidationResults along with the existing contact object in the Model to the View. This Validator control will grab the appropriate validation messages for the specified control/property and display any validation messages for that specific control. The following is the complete code for the Validator extension methods:

   1:  public static class ValidationControlExtensions

   2:  {

3:

   4:      public static string Validator(this HtmlHelper html, string controlToValidate, ValidationResults validationResults)

   5:      {

   6:          return Validator(html, controlToValidate, validationResults, new { style="color:Red;" });

   7:      }

8:

   9:      public static string Validator(this HtmlHelper html, string controlToValidate, ValidationResults validationResults, object htmlAttributes)

  10:      {

  11:          return Validator(html, controlToValidate, controlToValidate, validationResults, htmlAttributes);

  12:      }

13:

  14:      public static string Validator(this HtmlHelper html, string controlToValidate, string propertyName, ValidationResults validationResults, object htmlAttributes)

  15:      {

  16:          if (validationResults == null)

  17:          {

  18:              return null;

  19:          }

20:

  21:          var filteredResults = validationResults.Where(r => r.Key == propertyName);

  22:          if (filteredResults.Count() == 0)

  23:          {

  24:              return null;

  25:          }

26:

  27:          StringBuilder errorMessage = new StringBuilder();

  28:          foreach (ValidationResult validationResult in filteredResults)

  29:          {

  30:              errorMessage.Append(validationResult.Message);

  31:              errorMessage.Append("<br/>");

  32:          }

33:

  34:          TagBuilder builder = new TagBuilder("span");

  35:          IDictionary<string, object> attribueDictionary = new RouteValueDictionary(htmlAttributes);

  36:          builder.Attributes = ToStringDictionary(attribueDictionary);

  37:          builder.InnerHtml = errorMessage.ToString();

  38:          return builder.ToString();

  39:      }

40:

  41:      /// <summary>

  42:      /// ToStringDictionary is Internal to System.Web.Mvc.HtmlHelper

  43:      /// </summary>

  44:      /// <typeparam name="TKey"></typeparam>

  45:      /// <typeparam name="TValue"></typeparam>

  46:      /// <param name="dictionary"></param>

  47:      /// <returns></returns>

  48:      internal static Dictionary<string, string> ToStringDictionary<TKey, TValue>(IDictionary<TKey, TValue> dictionary)

  49:      {

  50:          if (dictionary == null)

  51:          {

  52:              return new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);

  53:          }

  54:          return dictionary.ToDictionary<KeyValuePair<TKey, TValue>, string, string>(entry => Convert.ToString(entry.Key, CultureInfo.InvariantCulture), entry => Convert.ToString(entry.Value, CultureInfo.InvariantCulture), StringComparer.OrdinalIgnoreCase);

  55:      }

  56:  }

One note here is that you can see I'm using a class called TagBuilder inside my method. This is actually an internal class in the System.Web.Mvc assembly. I just cracked open Reflector and did a complete copy/paste of that code into my own assembly so that I could leverage it. But what would be really nice is if Microsoft would change the accessibility on that class to public to more easily enable scenarios like this when people want to build their own control extension methods.

EntLib Validation Application Block - Subclassing PropertyProxyValidator for ValueConvert

Steve Michelotti — Mon, 16 Jun 2008 19:19:57 GMT

The Enterprise Library VAB provides the PropertyProxyValidator for ASP.NET applications so that you can attach it to a single control and it will display any validation messages for that business object property. This automatic UI validation is great because it avoids duplicating your business layer validation logic in your UI. Additionally, you can just use ONE validator control whereas using traditional ASP.NET validation controls you might need to attach 3-4 validation controls to a single UI element (e.g., RequireFieldValidator, RangeValidator, RegexValidator, etc.) which can clutter your aspx pages quickly.

However, one of the gotchas with working with the PropertyProxyValidator control is that, while it is quite elegant for strings, you have to do a little extra work for data types such as DateTime. Specifically, if you are working with a DateTime, you have to attach a ValueConvert method to your PropertyProxyValidator control in which you perform the data type conversion. The following code snippet is directly out of the VAB documentation:

   1:  protected void dateOfBirthValidator_ValueConvert(object sender, ValueConvertEventArgs e)

   2:  {

   3:          string value = e.ValueToConvert as string;

   4:          try

   5:          {

   6:              e.ConvertedValue = DateTime.Parse(value, System.Globalization.CultureInfo.CurrentCulture);

   7:          }

   8:          catch

   9:          {

  10:              e.ConversionErrorMessage = "Date Of Birth is not in the correct format.";

  11:              e.ConvertedValue = null;

  12:          }

  13:  }

This extensibility is great but if I need to perform multiple DateTime validations like this throughout my application, I don't want to have to copy/paste this code everywhere. Even if I encapsulate it in a static utility method, I still have to go through the pain of wiring up an event for any control where I need this just to make that 1-line call to the utility method.

So...a better approach is to simply subclass the PropertyProxyValidator control. In the following example, I just wire up the conversion in the contructor. This enables me to avoid having to wire up the event in the aspx code and and also enables me to avoid having to include the event in the code behind. I just specify the DateTimePropertyProxyValidator in my aspx code the normal way:

   1:  <asp:TextBox id="txtDateOfBirth" runat="server" />

   2:  <vab:DateTimePropertyProxyValidator ID="dobVal" runat="server" ControlToValidate="txtDateOfBirth" PropertyName="DateOfBirth" SourceTypeName="Person"/>

The same pattern could obviously be used for other data types. Below is the complete code for the DateTimePropertyProxyValidator:

   1:  public class DateTimePropertyProxyValidator : PropertyProxyValidator

   2:  {

   3:      public DateTimePropertyProxyValidator()

   4:      {

   5:          this.ValueConvert += OnValueConvert;

   6:      }

7:

   8:      private void OnValueConvert(object sender, ValueConvertEventArgs e)

   9:      {

  10:          DateTime result;

11:

  12:          if (DateTime.TryParse((string)e.ValueToConvert, out result))

  13:          {

  14:              e.ConvertedValue = result;

  15:          }

  16:          else

  17:          {

  18:              e.ConversionErrorMessage = "Date is not in the correct format.";

  19:              e.ConvertedValue = null;

  20:          }

  21:      }

  22:  }

EntLib Validation Application Block - Required String Validator

Steve Michelotti — Fri, 13 Jun 2008 03:23:24 GMT

In a previous post I discussed validating strings with the VAB in the context of ASP.NET applications. In summary, you must have a NotNullValidator and also a StringLengthValidator that prevents a string length of zero on the lower bound and prevents a string length above your upper bound (e.g., 50 characters). That attribute might look like this:

   1:  [StringLengthValidator(1, 50, MessageTemplate="First Name must be 1-50 characters.")]

But the problem is that the StringLengthValidator is really doing 2 jobs - one to check if the user entered a value and another to check the upper bound. Although including the NotNullValidator complete and correct, it doesn't do much in the context of asp.net applications which default to an empty string.

So from a user perspective, it would be nice to have one message if the user leaves it blank and another message if they've exceed the upper bound (or didn't follow an appropriate Regex pattern, etc., etc.). In other words, it would be nice to have a RequiredStringValidator so we could write our business object like this (notice we no longer have to care about the lower bound on the string length validator):

   1:  public class Person

   2:  {

   3:      [RequiredStringValidator(MessageTemplate = "First Name is required.")]

   4:      [StringLengthValidator(50, MessageTemplate = "First Name must be less than 50 characters.")]

   5:      public string FirstName { get; set; }

   6:  }

Also, specifiying a MessageTemplate on the RequiredStringValidator is optional.

So creating your own custom validator to do this is actually quite easy. The complete implementation follows:

   1:  public class RequiredStringValidatorAttribute : ValueValidatorAttribute

   2:  {

   3:      protected override Validator DoCreateValidator(Type targetType)

   4:      {

   5:          return new RequiredStringValidator(this.MessageTemplate, this.Negated);

   6:      }

   7:  }

8:

   9:  public class RequiredStringValidator : ValueValidator<string>

  10:  {

  11:      public RequiredStringValidator(string messageTemplate, bool negated) : base(messageTemplate, null, negated)

  12:      {

  13:      }

14:

  15:      protected override void DoValidate(string objectToValidate, object currentTarget, string key, ValidationResults validationResults)

  16:      {

  17:          if (string.IsNullOrEmpty(objectToValidate) != Negated)

  18:          {

  19:              LogValidationResult(validationResults, GetMessage(objectToValidate, key), currentTarget, key);

  20:          }

  21:      }

22:

  23:      protected override string DefaultNegatedMessageTemplate

  24:      {

  25:          get

  26:          {

  27:              return "Field cannot have a value.";

  28:          }

  29:      }

30:

  31:      protected override string DefaultNonNegatedMessageTemplate

  32:      {

  33:          get

  34:          {

  35:              return "Field is required.";

  36:          }

  37:      }

  38:  }

I've supported Negations for completeness but I can't really think of a real-world example where you'd want to use it in this context.

So overall, the RequiredStringValidator check for both null and empty string. Thus, you don't have to feel like you're kludging the StringLengthValidator into doing two different jobs.

EntLib Validation Application Block - Validate a string in ASP.NET

Steve Michelotti — Wed, 11 Jun 2008 01:27:42 GMT

You've created a class like this and all your unit tests pass just fine when you check for null strings or strings greater than 50 characters:

   1:  public class Person

   2:  {

   3:      [NotNullValidator(MessageTemplate="First Name is required.")]

   4:      [StringLengthValidator(50, MessageTemplate="First Name must be 1-50 characters.")]

   5:      public string FirstName { get; set; }

   6:  }

But then when you run it in an ASP.NET application with the PropertyProxyValidator validation control provided by VAB, your business object suddenly shows as valid even though the user left the text box blank.

   1:  <asp:TextBox ID="txtFirstName" runat="server" />

   2:  <vab:PropertyProxyValidator id="firstNameVal" runat="server" ControlToValidate="txtFirstName"

                                   PropertyName="FirstName" SourceTypeName="WebApplication1.Person"/>

Why is this happening? The reason is because the ASP.NET infrasture will put an empty string (i.e., a zero-length string) in that property rather than a null. In point of fact, the validator was not set up correctly to begin with. The intent is also to prevent an empty string. So to correct the implementation of the StringLengthValidator, you must give the lower bound of 1 as the first argument as shown here:

   1:  [StringLengthValidator(1, 50, MessageTemplate="First Name must be 1-50 characters.")]

Additionally, the VAB will allow you to specify whether you want the number specified for the lower/upper bound to be considered inclusvie/exclusive for the range.