Hi All,
What is the general feel people have here of validating a BO property in the setter when the validation request the use of a Command object and might take a long time?
For example, a good example might be when setting an account code on a root Business Object, there might be a requirement that the account code is unique, so the Rule object in theory would have to go to a database and find out if the given code is in fact unique. This could take 1 or 2 seconds.
So the question here is; is there another way of validating this property but doing it just before the object is saved? I guess its like a deffered Validation Rule.
Regards
I have rules that "hit the DB" but I leave the hits themselves in the rule mthods and let PropertyHasChanged fire the rules. I do not put them directly in the property set.
The first thing I do is change the priority for DB hit rules from the default of 0 to 1. That way they only run if all other rules for that property are valid. e.g. not blank, not too long, etc.
===================================================================
You could also do something like this if you want to defer the running of the DB rules until you click Save and check IsValid:
I wrote this the other day and it may help:
If you want to set all the properties on screen first (like in a web form) and then only figure it out once they have all been posted you can do something like this:
Create a rule which is assigned to a dummy property - call it anything you want. "My Fake Account Property". Then you need to make sure this 1 rule is called whenever you call IsValid - so override it and call this rule first and then call MyBase.IsValid. This way the rule is only checked once when all properties are set rather than multiple times as each property is changed. This design also works well for screens where there are many checkboxes and your rule is that at least 1 of them must be checked.
Joe
JoeFallon1:
...The first thing I do is change the priority for DB hit rules from the default of 0 to 1. That way they only run if all other rules for that property are valid. e.g. not blank, not too long, etc...
I have thus far used the rule "short circuiting" feature very sparingly so the user knows everything that is wrong with the object. Is this a bad practice?
No it is not a bad practice. Just different.
I have a web app and a heavy DB load. I prefer to let the user fix all "std" errors before wasting a call to the DB. e.g. field is required and they did not fill it in - why bother asking the DB of the "" value exists?
Yes - this could cause the user to have to submit more than once - but only if they made mistakes the first time.
Joe
We have this case often, and we basically make our decision based on how much performance is going to be affected. We struggled a little bit philosophy-wise with this because we wanted everything to be consistent, but in the end we decided that in some cases it's better to provide delayed feedback than delayed performance.
So if we feel the check would be too costly we do a "Deferred Validation". But we do not tie the rule to a dummy property because we want the error provider to show it. We basically have a variable in our BO letting us know if we want to perform the deferred check or not. Then in our validation code we short circuit the check based on the variable, so that it returns true if we are not ready to run the validation. In the save of our object, we set the flag to run the deferred validations, and then check the validations on all of the properties that have a deferred check. If any come back broken, we cancel out of the save, otherwise we continue as normal.
Another thing to note is that we do our validation checks on the PropertyChange event which means the validation would fire on every keystroke. If you're firing the validations on the OnValidation event, the affects of the DB validation would be reduced.
HTH -stan
Copyright (c) Marimer LLC