By: Mats Helander
Copyright © Mats Helander 2004
The ValidateOnBeforePersistAll Property
This document will show you how to take advantage of the built-in object validation support in the MatsSoft NPersist Framework.
Object validation allows you to enter custom code that is called at certain points in an object’s life cycle in order to ensure that the object is in a valid state.
You can control exactly when in an object’s lifecycle it should be validated, but the default behavior is to validate objects before they are created, updated or deleted as part of a PersistAll() operation.
NPersist object validation works by allowing your persistent objects to implement the MatsSoft.NPersist.Framework.IValidatable interface.
This interface contains just one method – a Sub (a function returning void for C-sharpers) called Validate().
The Validate method takes no argument and is expected to validate the object and throw an exception if anything is wrong with the state of the object. If you want, you can throw the MatsSoft.NPersist.Framework.ValidationException exception, but you don’t have to. webwinkel laten maken
An example of the implementation of the Validate method on an Order object might be:
Public Sub Validate() Implements IValidatable.Validate
If m_OrderDate > m_ShippingDate Then
Throw New ValidationException( _
"Order date must not be later than shipping date!")
End If
End Sub
The NPersist framework is responsible for calling the Validate method on those of your objects that implement the IValidatable interface.
You can control when the calls to the Validate method are made by setting the properties of the ValidationManager, which is accessible through the ValidationManager property of the ContextManager.
For example, the following will ensure that your Validate method will be called when a client passes the object to the DeleteObject() method of the context manager, just before the object is registered as “up for deletion”:
myContextManager.ValidationManager.ValidateOnBeforeDelete = True
The following example, on the other hand, will make sure that the Validate method is called just before the SQL statement for removing the object from the database is generated and sent (which will happen when PersistAll() is called):
myContextManager.ValidationManager.ValidateOnBeforeRemove = True
If both properties are set to True, then the Validate method will be called at both these events.
The default setting for all of the ValidationManager properties is False, except for one property, which is True.
The ValidateOnBeforePersistAll property is the only property on the ValidationManager with a default value that is True.
It represents a special behavior that works as follows:
When you call the PersistAll() method on your ContextManager, the first thing that will happen – assuming the ValidateOnBeforePersistAll is set to True - is that all the objects that are registered as up for creation, up for deletion or up for being saved (the Dirty objects) are looped through and the Validate method is called at each of them. нарядные юбки
This means that all the objects that are about to be affected by the PersistAll operation (and that implement IValidatable) will be validated before the PersistAll operation commits.
If the Validate method of an object throws an exception, you can try to fix the object, try to call PersistAll again, fix the next object that throws a validation exception, and so on until no object throws a validation exception and the PersistAll operation goes on to commit. He did so to get a good grade,- buy college paper. Finally found.
While you can control exactly at what points you want the Validate method called for your objects, the default setting of validating all objects about to be affected by a PersistAll operation before the PersistAll commits is normally the most useful setting.
Since this is the default setting, all you have to do in order to get sensible validation behavior out of your persistent objects is to let them implement the IValidatable interface with its one method.
Turning off the ValidateOnBeforePersistAll property and setting others to True in order to customize the validation behavior further should only be relevant for rather special circumstances, and mostly you will never have to change the properties in the ValidationManager.
The exception could be if you wanted to turn off object validation altogether, in which case you’d simply turn ValidateOnBeforePersistAll to False.
What your Validate methods should contain is of course entirely up to you, but basically it should be code that validates the object so that the properties don’t contain any strange and unwanted values.
You can call the Validate method on your objects manually as well, of course, for example in order to check them before you even attempt to call PersistAll.
Another way of providing object validation is by implementing the IEventListener interface or by creating Observers containing validation logic. You can learn more about how to use this interface and the Observers in the document NPersist Observers, available at the documentation section of the NPersist web site.
Object validation with the IValidatable interface is a powerful yet easy-to-use way of ensuring your objects don’t save bad values to the database, and to enforce overall application integrity.
Have Fun and Happy Hacking!
/Mats Helander