Validation Application Block Ruleset in Enterprise Library 3.0 - Enterprise Library 3.0 Tutorials - Part III

Validation Application Block Ruleset in Enterprise Library 3.0 - Enterprise Library 3.0 Tutorials - Part III

by David Hayden ( Microsoft MVP C# ), Filed: Enterprise Library 3.0 Tutorials

 

This is part III in a multipart tutorial of the new Validation Application Block in Enterprise Library 3.0. The first two parts are:

Up until now we have been using the Validation Facade Class and ValidationFactory Class to validate an instance of Subscriber against one set of rules. However, it is often more realistic to want to validate your class using multiple sets of rules. Maybe with the subscriber class we have using to date, we have a set of rules that define a valid subscriber, but we also have another set of rules that determine whether the subscriber can be persisted to the database. It is often that we may want to save a subscriber to the database in a temporary state until we have all the correct information we need to make him/her a valid subscriber.

Ruleset

Still purely focusing on the use of ValidatorAttributes to validate our classes, there are NamedParameters for which you can add additional information to your attributes. One of the NameParameters is called Ruleset, which allows you to define a family of rules that act together to validate your classes.

For example, if we look at the Subscriber Class we have been using thus far:

 

public class Subscriber
{
    private string _name;

    [NotNullValidator]
    [StringLengthValidator(1,200)]
    public string Name
    {
        get { return _name; }
        set { _name = value; }
    }

    private string _emailAddress;

    [NotNullValidator]
    [EmailAddressValidator]
    public string EmailAddress
    {
        get { return _emailAddress; }
        set { _emailAddress = value; }
    }

    public Subscriber() {}
}

 

Let's say that for persistence purposes, I really only care that the Name and EmailAddress of the would be subscriber is not null, because I don't allow a Null Value in the database fields. However, I really don't care if the other rules are valid for persistence. If this is the case, I can create a Ruleset, called Persistence, that distinguishes the null rules separate from the others, and decorate my classes as such to show the distinction:

 

public class Subscriber
{
    private string _name;

    [NotNullValidator(Ruleset="Persistence")]
    [StringLengthValidator(1,200)]
    public string Name
    {
        get { return _name; }
        set { _name = value; }
    }

    private string _emailAddress;

    [NotNullValidator(Ruleset="Persistence")]
    [EmailAddressValidator]
    public string EmailAddress
    {
        get { return _emailAddress; }
        set { _emailAddress = value; }
    }

    public Subscriber() {}
}

 

Validation and ValidationFactory Overloaded Methods Using Ruleset

As you might guess, there are overloaded methods in both the Validation and ValidationFactory Classes that allow you to specify you ownly want validation to occur using a particular set of rules ( Ruleset ) as such:

 

Validation.Validate(subscriber, "Persistence");

 

or

 

IValidator<Subscriber> subscriberValidator =
  ValidationFactory.CreateValidator<Subscriber>
("Persistence"); ValidationResults results = subscriberValidator.
Validate(subscriber);

 

Conclusion

The fact that you can define Rulesets to specify a family of rules to validate your classes allows you a lot more flexibility in how you can use the Validation Application Block in Enterprise Library 3.0.

Written By: David Hayden ( Microsoft MVP C# )

Filed: Enterprise Library 3.0 Tutorials

posted on Monday, December 25, 2006 12:56 PM

Main

News

Green Tea

.NET Development

Enterprise Library

Patterns & Practices