Data Annotations and Validation in MVC Part Two

This is the initial set up we need to run this data annotation validation project.

Now we are going to discuss the validation available in data annotation one by one.

Note: Data annotations are attributes we can find in the System.ComponentModel.DataAnnotations namespace. These attributes provide server side validation and framework also supports client side validation.

Custom Annotations

Imagine we want to restrict the address field value of a student to a limited number of words. For example we might say 50 words is more than enough for address field. You might also think that this type of validation (limiting a string to a maximum number of words) is something we can reuse with other modules in our application. If so, the validation logic is a candidate for packaging into reusable attributes.

So making the attributes reusable we are going to place all the custom annotation logic in one common place/folder, say attributes as we know all the validation annotations (such as Range, StringFormat ) ultimately derive from the ValidationAttribute base class. This base class is abstract and resides under System.ComponentModel.DataAnnotations namespace.

To keep validation logic in one place I have added an attributes folder name in application solution and added a class MaxWordAttributes class in it like this
To implement the validation logic, we need to override one of the IsValid methods provided by the base class. Overriding the IsValid version takes ValidationContext as a parameter. The ValidationContext parameter gives us access to the model type, model object instance, and friendly display name of the property we are validating, among other pieces of information.
The first parameter to the IsValid method is the value to validate. If the value is valid you can return successful validation result, but before we can determine whether the value is valid we need to know the count of the words in that field. So for that a programmer should pass how many values is too many for that property, to do that we need to create a constructor to accept number of words.
Now we have parameterized the maximum word count so we can implement our validation logic and catch the validation error.
Here we just split the value and compare the count with maxWords. If it is greater than that it should return validation error message otherwise a successful result.

Here the problem with the last line new ValidationResult("Too long Address!") we can see this is just a hardcoded error message. To write a good quality code we never want hardcoded error message. We always want to pass the error message and that error message should display instead of this hardcoded one.

To do that we just need to change our code a bit.
We made two changes in our above code.

• First we place the default error message to the base constructor. We should pull default error message from a resource file if we build an international stander application.
  
  
• Second, notice how the default error message includes a parameter placeholder ({0}). The placeholder exists because the second change, the call inherited FormatErrorMessage method, will automatically format the string using the display name property.

FormatErrorMessage ensures that we use correct error message string even if the string is localized into a resource file. We can use our custom annotation attributes in the following ways.

In first use we will get default error message if validation failed and in second use we will get the message that we set in our model.


Remote

The ASP.NET MVC frameworkadds an additional Remote validation attribute. This attributes is in System.Web.Mvc namespace.

The Remote attributes enable us to perform client side validation with server callback. Take for example the UserName property is of a StudentModel, we are not going to allow the user name that already exists in our database. Which is to say for every student there must be a unique UserName. To achieve this we need to use Remote attributes.
Inside the attributes we can set the name of the action and the name of the controller the client should call. The client code will send the value the user enters for the UserName property automatically and an overload of the attributes constructor allows us to specify additional fields to send to the server.
For example if user has hard coded string list we can easily replace that string list with the value we get from database. When we run the application and try to enter value that is inside the string list it will show validation failed error message.

Conclusion

In this article, we learned about the custom data annotation validation in ASP.NET MVC framework. If you have any question or comments regarding this article, please post it in the comment section of this article. I hope you like it.