Self Validation Check...

Topics: Validation Application Block
Mar 21, 2007 at 3:07 PM
Edited Mar 21, 2007 at 3:07 PM
I just want to double-check the behavior I am seeing in code.

Self Validation works in combination with validators assigned to the class.

Therefore, if you have a class like:

public class Address
    private string _zipCode;
		MessageTemplate = "ZipCode Invalid Length")]
    public string ZipCode
        get { return _zipCode; }
        set { _zipCode = value; }
    public void DoValidate(ValidationResults results)
        ValidationResult result = new ValidationResult
				("Error Message", typeof(Address), "","", null);
        ValidationResult result2 = new ValidationResult
				("Error Message2", typeof(Address), "", "", null);

The ValidationResults for an object instance will include both the results from the Self Validation as well as the results from the StringLengthValidator on ZipCode.

This is what I am experiencing and what I prefer, but just want to verify this is how it is supposed to work. Mentioning this in the documentation would be useful.




David Hayden
Microsoft MVP C#
Mar 21, 2007 at 5:57 PM

The validation block is cool and we love it.

I am looking for documentation/sample code for how a client would call SelfValidation.

Also, it would be great if you point me to sample articles which provide nested objects validation and custom validation. I have been searching for these topics for a while without any success.

Thanks a lot for your time.
Mar 21, 2007 at 6:54 PM
It appears that the validation block doesnt do anything about preventing objects from becoming invalid? For example, if a property does not allow null values, the property can still be set to a null value. Is this the approach that devs are taking with thier domain objects these days? I've always written defensive code that doesnt allow an object to ever be invalid. Can someone explain to me why we should allow our objects to have values set to invalid values?
Mar 21, 2007 at 7:24 PM
Here is a Self Validation Tutorial I put together:

Business Object Validation Using Validation Application Block - Self Validation Option - Enterprise Library 3.0

The beauty is that Self Validation is invoked just like any other validation.




David Hayden
Microsoft MVP C#
Mar 21, 2007 at 8:40 PM
The Validation Application Block does not replace nor expect you to stop normal property and argument checking. If a property or parameter is invalid, you need to throw an exception right away. You can use the Validation Application Block to help with this type of validation if you want by either creating your own validators or using the ones provided with VAB.

However, you probably know that validation is far from that simple in the real world. Often validation is much more complex and based on the value of several properties ( object state ). You also can use the VAB to check if a Customer is a "Gold Customer", for example, which is less about the object being invalid and more about business rules.

You also have situations when the object is the parameter:

public void Save(Customer customer);

so defensive programming would say you should not trust that the customer being provided is indeed valid so you better validate it.

That being said, this is where the Policy Injection Application Block comes into play. You could use it in coordination with the VAB to intercept method calls and property settings to do validation on the spot, allowing you to do that defensive programming without writing the code.

I have a couple of tutorials on it here that may help:

Policy Injection Application Block and Validation

Policy Injection Application Block and Logging




David Hayden
Microsoft MVP C#
Mar 21, 2007 at 10:52 PM
Dave - your assumption and observation of how self-validation works with other validators is correct. We're very close to locking everything down for this release, but I'll see if we can get this clarified in the final docs.

jnapier - the goal of the validation block is to provide a flexible way of seeing if an object is valid (for some definition of valid - there may be multiple if you have multiple rulesets). It was not a goal to prevent people from creating invalid objects in the first case. There are often many valid scenarios where you may want to have invalid objects (pun intended). For example, you may want to display the invalid object in a UI and ask the user to correct the data. It's hard to do this if you can't create the object in the first place.

If you wanted to prevent the object from becoming invalid in the first place, you could write code in your class to have it validate itself (using the VAB) at construction or when the data changes.