There are quite a few examples of using the attributes from System.ComponentModel.DataAnnotations out there in your ASP.NET MVC applications. If you haven’t been keeping up with what’s new in ASP.NET MVC 2, one of the biggest improvements is in the area of validation – which is now automatic if you decorate your models with the attributes. I recommend you check out ScottGu’s latest epic post on the topic to get up to speed.
Continuing with the Gu’s example, here is our Person class and the applied validation attributes:
public class Person {
[Required(ErrorMessage = "First Name is required.")]
[StringLength(50, ErrorMessage = "First Name must be under 50 characters.")]
public string FirstName { get; set; }
[Required(ErrorMessage = "Last Name is required.")]
[StringLength(50, ErrorMessage = "Last Name must be under 50 characters.")]
public string LastName { get; set; }
[Required(ErrorMessage = "Age is required.")]
[Range(0, 120, ErrorMessage = "Age must be between 0 and 120.")]
public int Age { get; set; }
[Required(ErrorMessage = "Email is required.")]
[Email(ErrorMessage = "You did not enter a valid email.")]
public string Email { get; set; }
}
This works great, but we can take it one step further and eliminate all the explicit error message strings by using a resource file. To add one, hit Ctrl+Shift+A to launch the Add New Item dialog. You can enter any name you like, I choose to keep it simple and named it Resources.
Next, we’ll add our error message strings to the resource file. Make note of the format items ({0}, {1}, etc.), as this is how the property names and validation attribute parameters are added to the error message. I’ll explain how this works later in this post. It’s also important to make sure the Access Modifier is set to Public. If it’s set to Internal, ASP.NET MVC 2’s DataAnnotations Model Binder won’t validate the property at all. This took me a few minutes to figure out what was happening, so don’t make the same mistake I did.
Now that we have our Resource file created and the validation error messages defined, we can change our Person class to make use of them. To get this working, all you need to do is specify the ErrorMessageResourceName and ErrorMessageResourceType when applying a validation attribute. Here’s our new Person class making use of the resources.
public class Person {
[Required(ErrorMessageResourceName = "Required_ValidationError", ErrorMessageResourceType = typeof(Resources))]
[StringLength(50, ErrorMessageResourceName = "Required_ValidationError", ErrorMessageResourceType = typeof(Resources))]
public string FirstName { get; set; }
[Required(ErrorMessageResourceName = "Required_ValidationError", ErrorMessageResourceType = typeof(Resources))]
[StringLength(50, ErrorMessageResourceName = "StringLength_ValidationError", ErrorMessageResourceType = typeof(Resources))]
public string LastName { get; set; }
[Required(ErrorMessageResourceName = "Required_ValidationError", ErrorMessageResourceType = typeof(Resources))]
[Range(0, 120, ErrorMessageResourceName = "Range_ValidationError", ErrorMessageResourceType = typeof(Resources))]
public int Age { get; set; }
[Required(ErrorMessageResourceName = "Required_ValidationError", ErrorMessageResourceType = typeof(Resources))]
[Email(ErrorMessageResourceName = "Email_ValidationError", ErrorMessageResourceType = typeof(Resources))]
public string Email { get; set; }
}
When we test the validation, we should see that the validation still works, and it’s now using our generalized error messages, substituting the property name and, if the validation attribute has any, the attribute parameters (as in the case of StringLength or the Range attributes).
It works great now, but that code still looks a little verbose to me. I don’t want to specify the resource string name and resource type every time I use one of the attributes. My preferred approach is to subclass the validation attributes with my own of the same name. Let’s do that now. The strategy here is to pass the heavy lifting off to the original attribute’s constructor (if necessary), and initialize the 2 properties that we were hard-coding before.
public class RequiredAttribute : System.ComponentModel.DataAnnotations.RequiredAttribute {
public RequiredAttribute() {
ErrorMessageResourceName = "Required_ValidationError";
ErrorMessageResourceType = typeof (Resources);
}
}
public class StringLengthAttribute : System.ComponentModel.DataAnnotations.StringLengthAttribute {
public StringLengthAttribute(int maximumLength) : base(maximumLength) {
ErrorMessageResourceName = "StringLength_ValidationError";
ErrorMessageResourceType = typeof (Resources);
}
}
public class RangeAttribute : System.ComponentModel.DataAnnotations.RangeAttribute {
public RangeAttribute(int minimum, int maximum) : base(minimum, maximum) {
InitializeErrorMessageResource();
}
public RangeAttribute(double minimum, double maximum) : base(minimum, maximum) {
InitializeErrorMessageResource();
}
public RangeAttribute(Type type, string minimum, string maximum) : base(type, minimum, maximum) {
InitializeErrorMessageResource();
}
private void InitializeErrorMessageResource() {
ErrorMessageResourceName = "Range_ValidationError";
ErrorMessageResourceType = typeof(Resources);
}
}
public class EmailAttribute : RegularExpressionAttribute {
public EmailAttribute() : base("^[a-z0-9_\\+-]+(\\.[a-z0-9_\\+-]+)*@[a-z0-9-]+(\\.[a-z0-9-]+)*\\.([a-z]{2,4})$") {
ErrorMessageResourceName = "Email_ValidationError";
ErrorMessageResourceType = typeof (Resources);
}
}
This really cleans up our model class, which now looks like this:
public class Person {
[Required]
[StringLength(50)]
public string FirstName { get; set; }
[Required]
[StringLength(50)]
public string LastName { get; set; }
[Required]
[Range(0, 120)]
public int Age { get; set; }
[Required]
[Email]
public string Email { get; set; }
}
Much better, and our validation still works as we expected, without all the string and type duplication. The only problem I see now is that our error messages use the exact property name, which isn’t always what we want. For example, when the user submits the form without entering a value in the FirstName field, they receive the error message “FirstName is required.” I would much rather see “First Name is required.” instead. Good news! They made this really easy to change for nitpickers like me.
To get our property name showing up nicely, all we have to do is apply the DisplayName attribute to the FirstName property.
[DisplayName("First Name")]
public string FirstName { get; set; }
This also has the added benefit of updating the FirstName field’s label as well, since we’re using ASP.NET MVC 2’s strongly typed label HTML helper (which uses the property name if no display name is available).
As a bonus, if we enable client side validation, everything still works! You can see an example of this in the sample code (link below).
How it Works: FormatErrorMessage()
Let’s take a peek inside the FormatErrorMessage() method on the StringLengthAttribute:
public override string FormatErrorMessage(string name) {
return string.Format(CultureInfo.CurrentCulture, base.ErrorMessageString, new object[] { name, this.MaximumLength });
}
Every ValidationAttribute will either inherit this method, or implement their own (if it has additional parameters, like String Length, which has a maximum length that is supplied to the attribute. As you can see, this method is simply using string.Format, and supplying the name as {0} and the MaximumLength property as {1}. Simple enough, right?
If you want to poke around in the code, you can download the sample here.