ValidationRules.AddInstanceRule Question

DanielBarla posted on Tuesday, July 10, 2007

Hi Guys,

I have a scenario where a specific business object must behave in different ways w.r.t. validations, essentially based on which screen / part of a process it is being accessed from.  Essentially what happens is that I have a method on the business object which can be called in order to apply additional sets of validation rules.  This allows the calling screens to apply the relevant validations to the object (at runtime) when these validations are needed for specific points in a process.  There are two questions I have:

1)  When I use the above mentioned method, I call ValidationRules.AddInstanceRule, as expected.  However, if something has already triggered validation on the object prior to the AddInstanceRule call, the new rules do not reflect / take effect on the object, since the  framework's code caches the list of rules to apply, and will effectively not  "un-cache" them until the object is destroyed.  This means that I'm stuck having to initialise the validations in, or right after the constructor, and this is not ideal. I'm wondering if anyone's run into this problem, and whether you've come up with some creative solutions to it.

2) I'm aware that allowing screens to add validation rules is generally considered to be bad practice, since a degree of control regarding the validation rules is removed from the business object.  A cleaner approach would be for me to create a base class from which specific implementations could inherit, and each of these could then apply the relevant validations.  Unfortunately, the project in question already has a large number of business classes, and I'm not looking to multiply them just for the purposes of validation.  Do you have a clean solution which doesn't require multiple classes, and remains relatively dynamic?

Thanks,

Daniel Barla-Szabo

ajj3085 replied on Tuesday, July 10, 2007

It sounds like you should have multiple classes, one for each use case.

david.wendelken replied on Tuesday, July 10, 2007

I think you need to re-think your rule definitions, not add or subtract rules after-the-fact!

Example (in your terms, as I understand them):

From screen "InitialEntry", the property "BirthDate" is optional.

From screen "PrepareToPay", the property "BirthDate" is required.

So, you've framed the solution as "Add a Field Required rule on BirthDate when on screen "PrepareToPay".

Same example, in business rule terms:

The business object has two states, InitialEntry and ReadyToPay.  This is denoted by a read/write property called, imaginatively enough, BusinessProcessState.

The PrepareToPay screen is responsible for setting the BusinessProcessState to ReadyToPay.

The business rule is:

BirthDate is required when BusinessProcessState = "ReadyToPay".

The above rule checks the BusinessProcessState and if it is not ReadyToPay, it returns success.

If BusinessProcessState = ReadyToPay, then it checks to see whether the BirthDate is filled in, and returns success or failure as appropriate.

 

In this example, the rule is always present.  And it's much cleaner to code and understand than adding/subtracting rules at runtime, or having lots of different (but mostly the same) classes with different rules in them.

 

 

 

DanielBarla replied on Wednesday, July 11, 2007

Thanks for the reply.  Yepp, your example is quite similar to my requirements, so you understood correctly.

I like your solution, so far I've stayed away from doing it that way since it requires implementing custom validation rules for each case (where the standard ones typically would have done just fine).  However hearing other people's opinion is starting to nudge me in that direction :)

I'm thinking that perhaps I should look into creating a set of validations that implement the specification pattern (In short, a way of selecting objects as well as composing these criteria, using AND, OR, NOT, etc. One of the better explanations I've seen is on DNRTV, here). This would allow easily re-using the basic validations whilst also providing composability at the same time.

In either case, thanks for the the ideas!

david.wendelken replied on Wednesday, July 11, 2007

DanielBarla:

I like your solution, so far I've stayed away from doing it that way since it requires implementing custom validation rules for each case (where the standard ones typically would have done just fine).  However hearing other people's opinion is starting to nudge me in that direction :)

Learning how to do custom validation rules is "time well spent".  :)