Proper way to validate multiple required properties

Proper way to validate multiple required properties

Old forum URL:

ballistic posted on Wednesday, August 11, 2010

I have a class "Conversation" that has a fromMemberId and toMemberId.

What I need to do is make sure that toMemberId has not previously blocked fromMemberId. This means that I need to have BOTH fields before I can check to see if the interaction is valid (member has not blocked the other member).

The way Csla does the validation is once a property has been set. So this means, that when I validate fromMemberId, I have to check if toMemberId also exists and if it does, check if it is blocked.  I have to again do this when I validate toMemberId.

The problem with this approach is that if the toMemberId is never set, validation will never occur and Save will be allowed.

How are people dealing with dependent properties?

RockfordLhotka replied on Wednesday, August 11, 2010

It sounds like you have two rules?

The first rule is that both fields are required - which is a pretty simple dual property rule.

Then you have a validation rule that should run if the required rule succeeds. You can use rule priorities for this - just have this rule run at a higher priority than the required rule.

That'll block saving - because either the required rule will fail, or the validation rule might fail - so the object will only be valid if both values are present and the validation succeeds.

ballistic replied on Wednesday, August 11, 2010


Just want to make sure that when say "dual property rule" you are referring to the AddDependentProperty?

Also, I have never been able to get the short-circuiting to work (been using Csla since 2.1).  I have reviewed the 3.8 video on validation and according to it, by default, anything < 0 will always run, but anything >=0 will only run if no previous errors.

I have set up my rules as:
fromMemberId with priority 10
toMemberId with priority 20
isBlocked with priority 30

Even with an error in validation with priority 10 or 20 and setting e.StopProcessing = true, isBlocked is still executed. Should I set these as negative and have isBlocked be the only positive one?

Edit: When I add a new Conversation, I use BeginBatchLoad which suppresses rule checking and once all properties have been set, I turn rule checking back on and run CheckRules. Not sure if this would have an impact.

 - Andy

RockfordLhotka replied on Wednesday, August 11, 2010

Yes, what I mean by dual is that the rule is attached to both properties, and the properties are interdependent. Like the start/end date properties in the Project class in ProjectTracker. They go into and out of valid state together.

Short-circuiting is per-property, which might be the source of confusion. When short-circuiting occurs, it stops processing further rules for the specific property, but not for other properties.

If you have a dual rule at pri 0, that should stop processing of pri 1+ rules on both properties.

ballistic replied on Thursday, August 12, 2010

Thank you for clearing that up.  I had assumed it would stop all validation that had a higher number, regardless of the property.

One final question about validation...

When setting the IsBlocked validation rule on one of the properties, the two ways to get the validation to trigger is by having the value change, or running CheckRules. When adding a new Conversation, I use EndBatchLoad which calls CheckRules to run all my validation.

However, when updating the object, I do not like to run CheckRules and have it run all the validation methods. Instead, I like having it validate only the properties that changed.

Now since I am tying IsBlocked to a property, I have to make sure that whenever I update my object, that property gets set with a new value.  This works, but I'm afraid of sometimes forgetting to set that property, which would not run the IsBlocked validation method.

Is there any way around that?

RockfordLhotka replied on Thursday, August 12, 2010

You can call CheckRules() for a specific property, otherwise I'm not sure what to suggest.

Copyright (c) Marimer LLC