How to Use Data Annotations For ASP.NET MVC 3 Input Validation

if (!success)
{
var message = FormatErrorMessage(validationContext.DisplayName);
return new ValidationResult(message);
}
return null;
}
}

The attribute incorporates the effect of using the Range attribute on both fields and also ensures that, for example, scores such as 7-4 or 7-7 are detected as invalid. You use the SetScoreAttribute as in figure below.

public class New2MatchModel
{
[Required]
public String Player1 { get; set; }
[Required]
public String Player2 { get; set; }

[SetScoreAttribute("FirstSet2")]
public Int32 FirstSet1 { get; set; }
public Int32 FirstSet2 { get; set; }

[SetScoreAttribute("SecondSet2")]
public Int32 SecondSet1 { get; set; }
public Int32 SecondSet2 { get; set; }

[SetScoreAttribute("ThirdSet2")]
public Int32 ThirdSet1 { get; set; }
public Int32 ThirdSet2 { get; set; }
}

The attribute accepts as an argument the name of the related property (or properties) to take into account during validation. So you apply the SetScoreAttribute to, say, FirstSet1 and indicate FirstSet2 as the related property. In this way, the attribute can validate whether the score of the first set is consistent. Next, you reuse the attribute for the second and third set. It's a better solution, though not yet complete, as the figure below shows. As you can see, in fact, validation of individual sets works, but the score as a whole is still invalid.



Per-Class Validation

The lesson that these examples teach is that sometimes you need to proceed with a validation that applies at the class level, skipping over the apparent simplicity of validating property by property. In the specific example, we need to relate all six score properties and ensure that each individual property falls in the range 0-7, that two related properties describing a set fulfill other conditions, and that the score of the three sets forms a valid overall score for the match.

In .NET Framework 4 and ASP.NET MVC 3, each custom validation attribute can override the IsValid method, as the following example shows:

protected override ValidationResult IsValid(Object value, ValidationContext validationContext)
{
}

The ValidationContext type features a property named ObjectInstance, which references the instance being validated. By casting ObjectInstance to the type, you gain full access to all properties on the object you are going to validate.

protected override ValidationResult IsValid(Object value, ValidationContext validationContext)
{
var match = validationContext.ObjectInstance as NewMatchModel;
..
}

This gives you the flexibility and power to define a single validation attribute that, when applied at the class level (or to any property you like), can access the entire spectrum of values and check all the required business rules. In other words, you end up with something along the lines of the following code:

[TennisScoreAttribute]
public class New2MatchModel
{
[Required]
public String Player1 { get; set; }
[Required]
public String Player2 { get; set; }
..
}

You can still mix per-property and per-class validation, or you can incorporate all checks in a single attribute class. Note, though, that class-level validation is not triggered if some (decorated) properties are invalid. The figure below provides a demo of a class-level validation attribute.

public class OverallSetScoreAttribute : ValidationAttribute
{
protected override ValidationResult IsValid(Object value, ValidationContext validationContext)
{
var match = validationContext.ObjectInstance as New2MatchModel;
if (match == null)
return null;

// Perform a very minimal validation
var success1 = ApplyMinimalSetValidation(match.FirstSet1, match.FirstSet2);
var success2 = ApplyMinimalSetValidation(match.SecondSet1,
match.SecondSet2);
var success3 = ApplyMinimalSetValidation(match.ThirdSet1, match.ThirdSet2);

if (!(success1 && success2 && success3))
{
var message = FormatErrorMessage(validationContext.DisplayName);
return new ValidationResult(message);
}
return null;
}

private static Boolean ApplyMinimalSetValidation(Int32 set1, Int32 set2)
{

}
}

Clearly a class-level attribute needs to retain a reference to the type it validates, so unless you put a bit of effort into rewriting the code in Figure 6 to use reflection, the code is not reusable. On the other hand, if you don't much like the idea of writing a new attribute class every time, a better approach would be to use Microsoft's CustomValidation attribute at the class level. The attribute simply points to a method that performs the validation. The example in the figure below shows how to embed in the same class the logic for validation.

[CustomValidation(typeof(New2MatchModel), "ValidateMe"]
public class New2MatchModel
{
:
public static ValidationResult ValidateMe(New2MatchModel match)
{
:
}
}

It should be noted, though, that the first parameter of the CustomValidation attribute represents the validator type -- the type that contains the method you indicate as the second argument to the attribute (ValidateMe in the example in Figure above). What about the signature of ValidateMe? The method must be as follows:

public ValidationResult ValidateMe(Object value, ValidationContext context)

The first argument indicates the value of the property the attribute is attached to. If the CustomValidation attribute is attached to the class level, then the argument is a reference to the entire object. If the CustomValidation attribute applies at a single property, you get the value of the single property. In your definition of the method you can indicate a much more specific type than Object.

The IValidatableObject Interface

In the case of complex validation logic that spans over the entire class, you probably want to have a single place where all the rules are evaluated. A possible trick you could use to accomplish this consists of using a custom per-class attribute; another approach is based on using CustomValidation at the class level. In ASP.NET MVC 3, Microsoft also introduced the IValidatableObject interface for the same purpose, as the following example shows:

public interface IValidatableObject
{
IEnumerable<ValidationResult> Validate(ValidationContext context);
}

You basically implement the interface in your class and place the validation logic in the Validate method. Functionally speaking, this is equivalent to using a class-level attribute but probably makes for a cleaner solution.

The Way to Go

Validation is a matter of applying business rules. Sometimes validation can be done also on the client; at other times validation can be the same on the client and the server. Validation can even be a simple matter of applying basic rules to individual properties -- however, outside of tutorials or simple applications, this is almost never the case. So you're left to arrange your own validation layer around domain entities and/or view model objects. Per-class validation is the way to go; the details of how you implement per-class validation are up to you.