Martijn Boland » Validation

Validation in ASP.NET MVC – part 4: example with server-side and client-side validation

martijn — Mon, 08 Dec 2008 21:18:15 +0000

This is part 4 of a series of posts. See also:

In the previous posts, I described how we implemented model-based validation on the server-side in Cuyahoga with ASP.NET MVC and as the icing on the cake, we also added some client-side validation (also model-based).

Now, everything can be found in the Cuyahoga SVN sources but I have to agree that it can be a daunting task to check out the complete sources and find all pieces of the validation puzzle. Therefore, I’ve created a little sample application with everything from the previous posts combined.

Hopefully, this will make things a little bit clearer. You can download the sample app here. Visual Studio 2008 and ASP.NET MVC Beta are required.

Enjoy!

Validation in ASP.NET MVC – part 3: client-side validation with jquery validation

martijn — Mon, 08 Dec 2008 15:09:19 +0000

This is part 3 of a series of posts. See also:

In the first two parts, I showed how you can perform validation on the server side with Castle Validation attributes and extend that model with custom validation logic. With this, we have everything we need to properly validate our model.

For a better user experience though, it would also be nice that we could re-use (part of) our validation logic on the client-side. Luckily, lots of others have already looked into this and the only thing I had to do was to throw everything together and stir it a little bit .

The ingredients are:

The jQuery validation plugin (an obvious choice, since we were already using jQuery in Cuyahoga);
Monorail client-side code generator for jQuery validation (originally contributed by Gildas, but also many credits to the Castle Monorail guys for creating such a flexible infrastructure);
Model-based Client-side Validation for ASP.NET MVC (very inspiring blog post by Steve Sanderson).

How it works

The client-side validation is called via an HtmlHelper extension method ClientSideValidation:
<%= Html.ClientSideValidation(ViewData.Model, “my_form_id”)%>;
The HtmlHelper extension requests an instance of a BrowserValidationEngine that returns the client script for validation;
BrowserValidationEngine has a reference to an IValidatorRegistry instance that returns all (Castle) validators for the given model;
For each validator, the referenced IBrowserValidatorProvider generates the appropriate client script;
Finally, all generated client script code is combined and sent to the browser in a single javascript block.

The existing Monorail codebase proved to be of great value and could be used almost seamlessly. The only difference is the way the client code is generated. Originally, the validators generated css class attributes for the Monorail form helpers, but we don’t have those with ASP.NET MVC, so all client code is generated as jQuery validation rules.

Below, you can see the output of the validation helper for the new user form in Cuyahoga:

which results in this:

Summarizing validation

In this series of posts, I showed how we deal with validation in Cuyahoga and ASP.NET MVC. Personally, I think the nicest part of it is that we have our validation rules centralized and we only have to add one line of code to the view to enable client-side validation.

The code can be found in Cuyahoga SVN and more specifically in the validation sections and the ASP.NET MVC manager. I’ll try to make a standalone sample project with all the validation stuff somewhere in the near future.

Validation in ASP.NET MVC – part 2: custom server-side validation

martijn — Thu, 27 Nov 2008 13:56:32 +0000

This is a post in a series of posts. See also:

Validation in ASP.NET MVC – part 1: basic server-side validation

In the first post of this series, I showed how you can perform basic server-side validation on your model with help of the Castle Validator component. To summarize this post: the controller validates an object that is decorated with validation attributes with the help of an IModelValidator component and adds errors to the ModelState.

The first reason to abstract the validator was to prevent coupling of MVC controllers to the Castle Validators. But the abstraction also provides a very nice extension point. We can inject any kind of validator into the controller constructor as long as it implements the IModelValidator interface:

public LoginController(IAuthenticationService authenticationService, IModelValidator modelValidator)
{
    this._authenticationService = authenticationService;
    this.ModelValidator = modelValidator;
}

In the example above, the constructor requires an IModelValidator instance. In our case, Castle Windsor injects a CastleModelValidator instance that is registered in the container for IModelValidator. We’re already seeing the first extension: the IModelValidator interface has a generic inheritor.

Extending the ModelValidator

In many scenario’s, property validation with the generic CastleModelValidator will suffice, but sometimes you’ll need some extra validation. For example, when creating a new user, we want to check if the username doesn’t already exist. To perform this check, we created a UserModelValidator class that inherits CastleModelValidator.

The CastleModelValidator calls a virtual method PerformValidation() while validating via IsValid(). In UserModelValidator, this method is overriden and performs the check if the username is unique:

public class UserModelValidator : CastleModelValidator
{
    private readonly IUserService _userService;

    public UserModelValidator(IUserService userService)
    {
        _userService = userService;
    }

    protected override void PerformValidation(User objectToValidate, ICollection<string> includeProperties)
    {
        // First validate the property values via the Castle validator.
        base.PerformValidation(objectToValidate, includeProperties);

        // Check username uniqueness.
        if (ShouldValidateProperty("UserName", includeProperties)
            && ! String.IsNullOrEmpty(objectToValidate.UserName))
        {
            if (this._userService.FindUsersByUsername(objectToValidate.UserName).Count > 0)
            {
                AddError("UserName", "UserNameValidatorNotUnique", true);
            }
        }
    }
}

Because the modelvalidators are registered in the Windsor Container, we can inject any kind of service or data access component into the validator and thus making it very easy to perform custom validation logic that needs to check the database, or check an external web service.

Tying things together

We want the UsersController to use the custom UserModelValidator when ValidateModel() is called. All we have to do is to add UserModelValidator to the constructor of the controller and we’re done:

public UsersController(IUserService userService, UserModelValidator userModelValidator)
{
    this._userService = userService;
    this.ModelValidator = userModelValidator;
}

Finally, this is how it looks in the browser. Nice to see the custom validation error nicely integrated with the rest of the errors.

Other extension possibilities

In this post we’ve seen an example where we extended our CastleModelValidator to perform custom logic by calling another service. You might as well call a method on the object itself that is validated to perform custom business logic:

protected override void PerformValidation(MyClass objectToValidate, ICollection<string> includeProperties)
{
    base.PerformValidation(objectToValidate, includeProperties);

    if (! objectToValidate.CheckThatMyBizarreBusinessRuleIsValid())
    {
        AddError("MyProperty", "The object to validate is invalid.");
    }
}

You can also opt for plugging in a completely different library. CSLA fans can very easily implement their own version of IModelValidator, or you could write an IModelValidator implementation that uses the Validation Application Block from Enterprise Library.

The code

This is a series of posts that is directly inspired by Cuyahoga development. All code can be found in the Cuyahoga SVN trunk at https://cuyahoga.svn.sourceforge.net/svnroot/cuyahoga/trunk. The validation stuff sits in the Validation subdirectory of Cuyahoga.Core: https://cuyahoga.svn.sourceforge.net/svnroot/cuyahoga/trunk/Core/Validation. Note that Cuyahoga is work in progress. It’s not guaranteed that the code in SVN will be exactly the same as the sample code in this post.

Validation in ASP.NET MVC – part 1: basic server-side validation

martijn — Wed, 26 Nov 2008 12:41:48 +0000

Almost every single application has to deal with validating user input. With web applications, you can choose to do the validation on the client side or on the server side. In my opinion, validation should at least take place on the server side and optionally on the client side to improve the user experience. Therefore, I’m starting this series of posts with the basic needs: server-side validation.
For some background, also check the excellent post about validation by Steve Sanderson.

Validate the model and not the UI

In the past I used the ASP.NET WebForms validators. These do a proper job, but are also very much tied to the individual pages, so you have the validation logic scattered all over the place. For Cuyahoga 2, I really wanted a better solution where validation logic is centralized in the model (and removed from the UI layer).
There are already several solutions that make this possible. Microsoft PnP released the validation application block and recently (.NET 3.5 SP1), we have the DataAnnotations from ASP.NET Dynamic Data.

In Cuyahoga, we’re using the Castle Validator component to perform basic validation, mostly because we’re already using other components from the Castle stack and it just works fine. With Castle validators, you’re decorating properties of your Domain entities with attributes like:

[ValidateNonEmpty("UserNameValidatorNonEmpty")]
[ValidateLength(1, 50, "UserNameValidatorLength")]
public virtual string UserName
{
    get { return this._userName; }
    set { this._userName = value; }
}

Note that it’s also possible to decorate DTO’s or presentation models or whatever you want to call these data containers. In Cuyahoga for example, we have a LoginViewData class that is only used in the UI layer, that is also decorated with validator attributes. If we have a validation infrastructure we might as well (ab)use it .

IModelValidator

So how are we going to use the Castle validators with ASP.NET MVC?

First we have to make a decision where we want to validate the model. You can do this in the controller or in the service layer (if you one). Some people suggest doing validation in the data access layer but I think the responsibility of a data access layer is persisting and retrieving the model and nothing else.

I’ve chosen to validate the model from the controller because it’s a little bit more convenient as you don’t have to throw exceptions across layers and translate those exceptions to error messages for the user. For validation, all controllers inherit from a base controller that has a ValidateModel() method. This controller also has an instance of an IModelValidator interface to perform the actual validation, so we don’t pollute the controller too much with validation logic and also prevent coupling to a specific implementation.

At this point, the controller can validate, but to use the Castle validators we have to implement IModelValidator and pass that to the controller. But first: a base controller doesn’t know which type to validate, but a concrete controller does (assuming we’re only validating one concrete type in a controller) and therefore we created the IModelValidator interface. The CastleModelValidator class implements this interface.

Because we’re using the Castle Windsor IoC container we can wire everything together in the controller constructor:

public class LoginController : BaseController
{
    private readonly IAuthenticationService _authenticationService;
    /// 
    /// Create and initialize an instance of the LoginController class.
    /// 
    /// The authentication service
    /// The IModelValidator for LoginViewData
    public LoginController(IAuthenticationService authenticationService, IModelValidator modelValidator)
    {
        this._authenticationService = authenticationService;
        this.ModelValidator = modelValidator;
    }
}

In the container is the registered that when asked for an instance of IModelValidator, the container should return an instance of CastleModelValidator. The constructor in the code above, receives an instance of CastleModelValidatorand sets the ModelValidator of the base controller.

How it works: the login screen

The Login action of the LoginController performs validation after populating a LoginViewData instance via TryUpdateModel():

public ActionResult Login(string returnUrl)
{
    var loginUser = new LoginViewData();
    try
    {
        if (TryUpdateModel(loginUser) && ValidateModel(loginUser))
        {
             // do authentication and exception handling

ValidateModel() automatically adds all errors to the ASP.NET MVC ModelState, so we have to do very little to actually display the validation errors:

The code

This is a series of posts that is directly inspired by Cuyahoga development. All code can be found in the Cuyahoga SVN trunk at https://cuyahoga.svn.sourceforge.net/svnroot/cuyahoga/trunk. Please note that all ASP.NET MVC stuff sits in the Manager subdirectory of the Cuyahoga.Web: https://cuyahoga.svn.sourceforge.net/svnroot/cuyahoga/trunk/Web/Manager.