Is this proper use of Validation Rules ?

Is this proper use of Validation Rules ?

Old forum URL: forums.lhotka.net/forums/t/6199.aspx

lukky posted on Monday, January 19, 2009

Hi,

Since I'm using code generation for my BOs, I use partial class definition in a separate file to put all my customized code.

In some cases, I need to customize the setter of some properties because setting property A has an impact on the value of property B. Now, the generation takes care of creating bare bones setters/getters for each column in the table on which the BO is based. Any customizing to a setter/getter will be lost if the class is regenerated.

So, what I need is a way to call some code, that will be in my other "non-generated" file, every time a given property is changed. This is where Validation Rules come into play. The code generator is kind enough to generate a partial method for me to add my custom validation rules, so I'm thinking of using a validation rule to set property B based on the value of property A, and simply return true. My concern is that this will "break" the normal CSLA way of doing things.

Is this "safe" ? Or is there another mechanism I should be using ?

Thank you.

wjcomeaux replied on Monday, January 19, 2009

This is most of the reason I've always gone with split base classes instead of partial classes. With split base all you have to do is override the property in question in the editable portion of your code and you're golden.

With partial classes the only way to do that would be to mark the property as virtual and then override it in an inherited class, in which case you probably haven't gained a whole lot by using the partial classes in the first place.

Will

robert_m replied on Monday, January 19, 2009

What you are doing is perfectly valid. I've done the same thing in many BOs and everything is fine...

simon_may replied on Monday, January 19, 2009

You can also override OnPropertyChanged, then uyou need nod generate any extra code.

HTH

rsbaker0 replied on Tuesday, January 20, 2009

The validation rules method works fine, but remember that your rules may be called even when nothing has changed (e.g. someone explicitly calls ValidationRules.CheckRules()).

So, you have to be careful/clever in how rules that modify data work so they function properly even when the data hasn't been altered.

lukky replied on Tuesday, January 20, 2009

rsbaker,

Yes, this is what I've come to realize and it has me wondering if for those cases I shouldn't simply use a base class approach as suggested by someone else.

One other issue with using the validation rule is that it gets fired only after the actual SetProperty(), and in some cases I need to act before.

I guess base class + overriding is the only way to do what I want. It would be nice, though probably impossible to implement, if partial classes allowed you to "override" methods Wink [;)]

Thank you.

simon_may replied on Tuesday, January 20, 2009

Lukky, Maybe I am missing something here. Can you explain why overriding OnPropertyChanged will not do what you want. I use it extensively in my business objects to acheive what, I believe, you are trying to do.

Obviously you must call base.OnPropertyChanged in order that other PropertyChanged handlers are callled. This can be doen either before executing your code or after. Validation is executed during the call to the base.OnPropertyChange so you can decide whether to validate before or after your code is executed.

Here is a snippet from a nongenerated partial class file as an example.

protected override void PropertyHasChanged(string propertyName)

{

if (propertyName == "GroupRef")

Audit.GroupChanged = true;

if(propertyName == "Status")

Audit.StatusChanged = true;

if(propertyName == "Program")

Audit.ProgramChanged = true;

base.PropertyHasChanged(propertyName);

}

 

Regards

Simon

simon_may replied on Tuesday, January 20, 2009

Just seen that I have been wittering on about OnPropertyChanged and of course it i PropertyHasChanged. Ooops, sorry about that.

lukky replied on Tuesday, January 20, 2009

Simon,

I understand the idea, and it should  indeed do what I want.

I just need to rethink the logic of what I do when the property changes, as it's a bit more complicated than just setting another property. In my actual scenario, I make use of the old value of the property that's being changed, which is obviously not available in this override.

So thank you for brining it to my attention, as I'll definitely use it in simple scenarios.

Regards.

rsbaker0 replied on Tuesday, January 20, 2009

lukky:
rsbaker,

Yes, this is what I've come to realize and it has me wondering if for those cases I shouldn't simply use a base class approach as suggested by someone else.

One other issue with using the validation rule is that it gets fired only after the actual SetProperty(), and in some cases I need to act before.
...

I can't help with the latter problem, but I've managed to leverage my auditing implementation to help with rules like this.

I *really* know whether or not a property has been changed or not because I have a copy of the original value for any changed property, so  I can do some fairly complicated transformations via business rules that are NOP's if the rule fires when the property hasn't really changed.

Copyright (c) Marimer LLC