Validation Rule Flexibility

MadGerbil posted on Wednesday, December 06, 2006

I've an object that can be one of three different 'modes'.  It can be an employee, a student, or a private individual - just for an example.   Each one of these has a different set of business rules so when the object is created I ask what 'version' of the object is required and set the validation rules as the object is being created.

This is happening on the web in a wizard, so when the person goes onto step 2 if they decide to back track and change the mode from employee to student I want to be able to clear out the current validation rules and place a different set in there.

The current validation rules object doesn't have a 'clear' method.

Is there a way to make this work?  I don't wanna use inheritance because the differences between these three types is only 3-6 rules out of 20.

xal replied on Wednesday, December 06, 2006

I would add all the rules and inside the rule do something like:

If target.mMode <> "Student" Then
    Return True 
End If

xal replied on Wednesday, December 06, 2006

Sorry, I unintentionally hit "post".

Anyway, as for the reason, if you use type rules, the rules are only "created" once and apply to all objects of the same type. Creating a rule (by calling AddRules) takes far more time than that conditional check inside your rule, even when the rule may run several times.

Andrés

MadGerbil replied on Wednesday, December 06, 2006

Dude, that idea rocks!

Thanks a bunch - I can see how that would be much more flexible in the long run and much easier to work with over all.  Thanks a bunch.

ajj3085 replied on Wednesday, December 06, 2006

Andres suggestion is fine, but be careful.  It almost sounds like you have different use cases (adding a student, employee or private individual).  This could lead to problems down the road when the behavior of student becomes wildly different than employee or private person.  Not saying its for sure, only you know your requirements, but it is something you should watch for.

xal replied on Wednesday, December 06, 2006

Yes Andy, I tend to agree that if you have very different use cases, you need different objects, but his scenario is more similar to something like:

If the client lives in an appartment building, specify which floor, otherwise, it's not required.

So the rule would look like:

Private Shared Function .....
If Not target.mLivesInAnAppartmentBuilding Then
    Return True
End If
If target.mFloor.Equals(String.Empty) Then
    e.Description = "Specify a floor"
    Return False
Else
    Return True
End If
End Function

Yeah, I know it's not the perfect example, but the point remains, you're not going to make 2 Client objects just because one could live in an appartment and the other in a house...

Andrés

ajj3085 replied on Wednesday, December 06, 2006

I agree, but just thought a warning was in order anyway.  Just from the names of the classes, it seems like its at least possible that there are things you can do with a student that you can't with an employee, such as generate a transcript.

Actually your example is quite a good one to show how rules can change based on the state of the BO.

david.wendelken replied on Wednesday, December 06, 2006

MadGerbil:

I've an object that can be one of three different 'modes'.  It can be an employee, a student, or a private individual - just for an example.   Each one of these has a different set of business rules so when the object is created I ask what 'version' of the object is required and set the validation rules as the object is being created.

My wife is BOTH an employee of a university and a student.   In addition, in some of her dealings with the university, she is acting as an employee (reporting grades for her students), in others she is acting as a private individual (donating books to the university library from our own library).

So, I have to ask you, are you sure that a person can only be one of those three things at any one point in time?   Or is mode representing the role the person is acting within at a given point in time?

 

MadGerbil replied on Thursday, December 07, 2006

The concerns brought up by some posters in this thread are all valid; and that is because I wasn't very thorough in describing the object with which I'm working.

I have a check object (like a purchase order) and the type of payee can be student, employee, or business - so address I wish to collect may have some different options based upon whether or not I'm collecting a single name (for a business) or a first and last name for an individual.

Obviously I don't want to show the first name/last name field on a voucher that is of type Business - nor do I want to validate those fields. (or the validation should always return true)

The type of payee is important only for the address and some reporting purposes and the type of payee is a property of the object itself - not so much a description of separate objects.  That is to say, I don't have a student object, an employee object, and a staff object because there is no need for that.

So the concerns brought up in this thread are valid - if I were actually trying to somehow merge a student/employee/business into one object.  In that case, inheritance would make more sense and with that the business rules would obviously work themselves out.

 

 

ajj3085 replied on Thursday, December 07, 2006

Ahh, that does make much more sense.

david.wendelken replied on Thursday, December 07, 2006

I had an object that was used to display a variety of different transaction types.  Each transaction type had its own set of properties (some of which were used by more than one transaction type).

I only wanted my UI control to display the relevant properties for that transaction type (plus the headers).  So, I set up my object with a set of Show<PropertyName> booleans.  If the property applied to that transaction type, I set the Show<PropertyName> for it to true, otherwise I set it to false.  All the logic to set those booleans was in one function, and each property that might change what I could do called it after setting the new value.  (Plus, of course, the Fetch routine for loading it from the database.)

For the items in the control, I set the visible property on or off based upon the show property.  Worked very well.  Was even able to turn rows on or off (inserts/deletes just needed to show new data, updates needed to show new and old values) using this trick.

You could also put logic in the set properties to verify that the property is applicable before accepting the value, in case you don't trust your GUI programmers.   I never do - even if it's me. :)