Enterprise Library

FredNUG Code Samples

Steve Michelotti — Thu, 27 Aug 2009 16:30:28 GMT

Thanks to everyone who attended my presentation last night at FredNUG. The code samples can be downloaded here.

Enterprise Library Validation Application Block with MVC Binders

Steve Michelotti — Tue, 17 Mar 2009 03:17:22 GMT

A while back, I blogged about using the Enterprise Library Validation Application Block (VAB) with ASP.NET MVC. As MVC has matured as a framework, this scenario has becoming simpler. In early releases of MVC, I implemented the execution of the VAB validation in the controller methods. However, I now prefer to put that logic in the binders themselves. In earlier versions of the framework, the model binders that came out of the box dealt well with simple objects but if you had more complex View Models (as described in this post) then you had to roll your own binder. With the latest releases of MVC, the DefaultModelBinder that comes OOTB with MVC is now quite robust and is even capable of dealing with those more complex binding scenarios. Hence, my preferred method for performing the valiation is best described in this post by David Hayden here.

However, the one issue with that method is that, although the binder deals well with the complex object, you’ll still run into the same issue with the VAB when it comes to the Key property of the validation messages. That is, the key is the name of the business object property itself which does not always match the property of the view model. For example, let’s revisit the example from my previous post and update it to use this new method. We have our Model passed to our view defined as:

   1:  public class ContactViewData

   2:  {

   3:      public Contact Contact { get; set; }

   4:      public IEnumerable<State> StateList { get; set; }

   5:  }

We bind to our textbox like this:

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

Or, if you prefer the MVC Futures approach, like this:

   1:  <%=Html.TextBoxFor(m => m.Contact.FirstName) %>

So our mismatch is that when the FirstName is invalid, the key for the validation result will be “FirstName” but we were binding to “Contact.FirstName”. You have two basic options to tackle this type of situation:

Option 1 – Prepend appropriate prefix with your binder

This is basically a re-write of my original method by utilizing a custom model binder that derives from the DefaultModelBinder. This is also a hybrid of Hayden’s approach:

   1:  public class ContactModelBinder : DefaultModelBinder

   2:  {

   3:      protected override void OnModelUpdated(ControllerContext controllerContext, ModelBindingContext bindingContext)

   4:      {

   5:          var validator = ValidationFactory.CreateValidator(bindingContext.ModelType);

   6:          var validationResults = validator.Validate(bindingContext.Model);

7:

   8:          foreach (var result in validationResults)

   9:          {

  10:              string mvcKey = GetMvcKey(result);

  11:              bindingContext.ModelState.AddModelError(mvcKey, result.Message);

  12:          }

  13:      }

14:

  15:      static Dictionary<Type, string> propertyPrefixMap = new Dictionary<Type, string>()

  16:      {

  17:          { typeof(Contact), "Contact" },

  18:          { typeof(Address), "Contact.Address" }

  19:      };

20:

  21:      /// <summary>

  22:      /// Converts an Enterprise Library ValidationResult into the correct "key" to be used by MVC Views.

  23:      /// </summary>

  24:      /// <param name="validationResult"></param>

  25:      /// <returns></returns>

  26:      static string GetMvcKey(ValidationResult validationResult)

  27:      {

  28:          string result;

  29:          propertyPrefixMap.TryGetValue(validationResult.Target.GetType(), out result);

30:

  31:          if (string.IsNullOrEmpty(result))

  32:          {

  33:              return validationResult.Key;

  34:          }

  35:          else

  36:          {

  37:              return result + "." + validationResult.Key;

  38:          }

  39:      }

  40:  }

This upside is that you enable you model and validations to match precisely. The downside is that this model binder does not have a lot of re-use if you’re not using this model in multiple views.

Option 2 – Set your Html.ValidationMessage() differently

In this typical scenario, you’d set up your view like this:

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

   2:  <%=Html.ValidationMessage("Contact.FirstName") %>

Of course, this leads to the issue described above. As an alternative, you could use different name parameters like this:

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

   2:  <%=Html.ValidationMessage("FirstName") %>

The upside is that you could leverage a more re-usable binder as described in Hayden’s post. The downside is that it seems a little counter-intuitive to be using different parameters on the TextBox() and ValiationMessage() extension methods to represent the same business object property. Perhaps this mis-match “feels” a little better with the MvcFutures syntax:

   1:  <%=Html.TextBoxFor(m => m.Contact.FirstName) %>

   2:  <%=Html.ValidationMessage("FirstName") %>

Whichever way you end up choosing, you certainly have a couple of decent options. The fact that MVC was designed in such a flexible way to be able to give you these options in the first place speaks volumes.

Validation Application Block – Unit Test Validation Logic

Steve Michelotti — Wed, 28 Jan 2009 03:27:26 GMT

The Enterprise Library Validation Application Block (VAB) is a great library for putting your validation in your business layer where it belongs rather than in the UI. It allows us to apply attributes to the properties of our business objects like this:

   1:  public class Person

   2:  {

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

   4:      public string FirstName { get; set; }

5:

   6:      [StringLengthValidator(1, 20, MessageTemplate="Last Name must be between 1-20 characters.")]

   7:      public string LastName { get; set; }

   8:  }

But are you unit testing your validation code properly? Consider this test method:

   1:  [TestMethod]

   2:  public void Person_Validation_Test()

   3:  {

   4:      var person = new Person();

   5:      person.FirstName = "Bill";

   6:      person.LastName = "Gates";

7:

   8:      // Verify person is valid

   9:      var validationResults = Validation.Validate(person);

  10:      Assert.IsTrue(validationResults.IsValid, "Person should be valid.");

11:

  12:      // Now make first name invalid

  13:      person.FirstName = string.Empty;

  14:      validationResults = Validation.Validate(person);

  15:      Assert.IsFalse(validationResults.IsValid, "Validation failed. FirstName should have been invalid.");

16:

  17:      // Now make last name invalid

  18:      person.FirstName = "Bill";

  19:      person.LastName = string.Empty;

  20:      validationResults = Validation.Validate(person);

  21:      Assert.IsFalse(validationResults.IsValid, "Validation failed. LastName should have been invalid.");

  22:  }

At first glance, this test method might look ok. It tests the person to make sure it’s valid; it then makes FirstName invalid and then tests it; it then makes LastName invalid (while setting FirstName back to normal) and then tests it, etc. But actually, there is a long list of things that are *wrong* with that test method – do *not* unit test this way.

First off, a good unit test should only test ONE thing at a time. In other words, you should have a test method for the FirstName property, another for the LastName property, etc. In fact, you could have a test method for FirstName being string.Empty, another test method proving that FirstName is invalid when it is over 20 characters, etc. Additionally, trying to “reset” the FirstName property back to normal before testing the LastName validation is just asking for trouble. A test method constructed in this way is going to get monolithic and ultimately you’re going to forget to “reset” properly. Additionally, you want to strive for DRY (Don’t Repeat Yourself) in your unit tests and how many times do you want to “reset” various properties back to “normal”?

If that wasn’t enough, there is something even more harrowing with this test. That is: after FirstName is set to string.Empty and validity checked for, how do we *know* that the FirstName property is the thing that is causing this object to be invalid? Sure, it looks obvious from the method but it’s not explicit and it’s uncertain. What if setting the FirstName property actually made some composite validator invalid but the FirstName itself was perfectly valid? What if, when we got to the LastName validation, we didn’t remember to properly “reset” the FirstName property and we’re asserting LastName is invalid where it was really the FirstName test that came before it that was making it invalid? There are just too many opportunities to make mistakes. To simplify all of this, the unit tests can be re-written like this:

   1:  [TestMethod]

   2:  public void Person_FirstName_Is_Invalid()

   3:  {

   4:      var person = CreateValidPerson();

   5:      person.FirstName = string.Empty;

   6:      person.AssertWithKey("FirstName");

   7:  }

8:

   9:  [TestMethod]

  10:  public void Person_LastName_Is_Invalid()

  11:  {

  12:      var person = CreateValidPerson();

  13:      person.LastName = string.Empty;

  14:      person.AssertWithKey("LastName");

  15:  }

16:

  17:  public static Person CreateValidPerson()

  18:  {

  19:      var person = new Person();

  20:      person.FirstName = "Bill";

  21:      person.LastName = "Gates";

22:

  23:      ValidationResults validationResults = Validation.Validate(person);

  24:      Assert.IsTrue(validationResults.IsValid, "Person should be valid.");

  25:      return person;

  26:  }

Notice that each test method is testing only one property (you can fill in additional test methods to ensure it’s invalid when over 20 characters, etc.). Additionally, each test starts from a known, valid state by re-using the static CreateValidPerson() method (which, inside, Asserts that it is, in fact, valid). Most importantly, for each test, it uses the AssertWithKey() method to ensure that the *reason* it is invalid is, in fact, the property we’re interested in. This AssertWithKey() is a simple extension method:

   1:  public static void AssertWithKey<T>(this T target, string keyToCheck)

   2:  {

   3:      ValidationResults validationResults = Validation.Validate(target);

   4:      ValidationResult result = validationResults.FirstOrDefault(r => r.Key == keyToCheck);

   5:      Assert.IsNotNull(result, "Validation Failed. {0} should have been invalid.", keyToCheck);

   6:  }

Notice the use of the FirstOrDefault() extension method. The ValidationResults returned from the Validate() method is a collection which we can inspect to ensure that the key (the key is the property name) is tied to the validation result we are looking for and expecting – thus, ensuring that the test is in fact invalid *because* of the specific property we’re testing.

The above code was written for MSTest but can be easily adapted to NUnit, xUnit, or your unit testing framework of choice.

Enterprise Library Validation Application Block with ASP.NET MVC

Steve Michelotti — Sun, 05 Oct 2008 02:15:08 GMT

Several weeks ago (before the release of the CTP5 of MVC) I posted a way to leverage the EntLib Validation Application Block with MVC. Since then CTP5 has been released and this finally includes a mechanism for reporting validations. It is important to note that it does not include the mechanism for *how* to do validation but rather how to *report* validations. This is actually a great thing because, first off, it allows the flexibility to utilize whatever validation framework you please rather than forcing you into a specific framework. Additionally, it encourages validations to be handled in the business/domain layer rather than the presentation layer. Stephen Walther shows an example here for how to leverage the EntLib VAB with the latest version of MVC. In this post, I'm going to expand on that including discussing specific issues that need to be addressed in more real-world applications.

Let's take an example:

In the simple case, let's say we pass a Contact object as the Model on to the View. To display and validation the first name we can simple do this:

   1:  <%=Html.TextBox("FirstName")%>

   2:  <%=Html.ValidationMessage("FirstName") %>

Then in our server side C# code during postback we can do this:

   1:  foreach (var validationResult in validationResults)

   2:  {

   3:      this.ViewData.ModelState.AddModelError(validationResult.Key, null, validationResult.Message);

   4:  }

This is all well and good because the validationResult.Key is going to be "FirstName" (e.g., if the first name was not valid). Basically it is just the property name.

This worked fine because the property name matched the string we gave the the Html.TextBox() and Html.ValidationMessage() methods. We don't have to look far to see that this will not always be this simple. Let see what it looks like to show our Contact's Street Address:

   1:  <%=Html.TextBox("Address.StreetAddress")%>

   2:  <%=Html.ValidationMessage("Address.StreetAddress")%>

Notice that now we have to specify "Address.StreetAddress" because Address is a property on the Contact object. If the street address is not valid, the C# code above will not work because the validationResult.Key is going to be "StreetAddress" but the key we need for the MVC ViewPage is "Address.StreetAddress". So basically we need is a helper method that is going to translate the Key from the ValidationResult into the key needed for the ViewPage. That is, we want to translate "StreetAddress" into "Address.StreetAddress" in this case. Even more specifically, we have to set the "prefix" correctly because we know the property names are going to match.

There are several ways to solve this. One way is to use a simple property prefix map like this:

   1:  static Dictionary<Type, string> propertyPrefixMap = new Dictionary<Type, string>()

   2:  {

   3:      { typeof(Address), "Address" },

   4:      // Add other types here

   5:  };

6:

   7:  public static string ToMvcKey(this ValidationResult validationResult)

   8:  {

   9:      string prefix;

  10:      propertyPrefixMap.TryGetValue(validationResult.Target.GetType(), out prefix);

11:

  12:      if (string.IsNullOrEmpty(prefix))

  13:      {

  14:          return validationResult.Key;

  15:      }

  16:      else

  17:      {

  18:          return prefix + "." + validationResult.Key;

  19:      }

  20:  }

A couple things of note. I'm using a C# 3.0 collection initializer on the dictionary here. Then notice I'm using the "this" keyword to make ToMvcKey() an extension method. Now I can change the original C# foreach loop to look like this:

   1:  foreach (var validationResult in validationResults)

   2:  {

   3:      this.ViewData.ModelState.AddModelError(validationResult.ToMvcKey(), null, validationResult.Message);

   4:  }

There are many ways to make this solution more flexible. For example, we could create an overload for our extension method that allows us to pass a dictionary in since different objects might be in different places of the object hierarchy depending on the ViewPage. In any case, the flexibility that the MVC framework gives you to perform various tasks many different ways is a great thing.

Leverage EntLib Validation Application Block in MVC

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

UPDATE: This post is now out of date as of the CTP5 release of the MVC framework. For the lastest version, see this post here.

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.