Could BusinessBase.SetProperty<P>() return bool if PropertyHasChanged?

Could BusinessBase.SetProperty<P>() return bool if PropertyHasChanged?

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


Michael posted on Monday, January 05, 2009

Hi Rocky et al

I have found myself doing this quite a lot:

set
{
    bool propertyHasChanged = value != m_value;

    SetProperty<int>(ExampleProperty, ref m_value, value);

    if (propertyHasChanged)
        // do something
}


This would be more convenient:

if (
SetProperty<int>(ExampleProperty, ref m_value, value))
    // do something

Any thoughts?

Kind regards
Mike

skagen00 replied on Monday, January 05, 2009

The framework supported manner is to override PropertyHasChanged in the business object, which only is fired if a property value has changed - I realize the location is separated from the setter which may be undesirable for some, but just wanted to make sure you were aware of that.

Chris

 

Michael replied on Monday, January 05, 2009

Thanks for the reply Chris. I hadn't thought of overriding PropertyHasChanged. That works, but would be slightly less efficient than having SetProperty return bool, and less desirable as you've mentioned, especially if you have many properties making use of it. I'll use the override for now.

Mike

vdhant replied on Monday, January 05, 2009

Hi Chris
This issue has been discussed a few time in the past, with the below link being the most recent:
Determine whether SetProperty has changed the value - http://forums.lhotka.net/forums/thread/28210.aspx

In short though there was no solid action to make a change, just work arounds.

For something to change here i should guess Rocky would need to get involved.
Hope this helps
Anthony

Michael replied on Monday, January 05, 2009

Thanks Anthony, I did do a search before posting, but didn't see that one.

AndrewBurns replied on Thursday, January 08, 2009

I just ran into this issue and understand the need to hook PropertyChanged (vs running code after SetProperty) otherwise subscribers will be notified BEFORE your after code runs which can be about 99.99% guaranteed that isn't what you wanted.

What about adding an override to SetProperty where you could pass in a lamda/anonymous method that SetProperty could invoke before changing the value something along the lines of:
get { return GetProperty(TaxRateProperty); }
set
{
    SetProperty(TaxRateProperty, value,
        (o, n) =>
        {
            Log.DebugFormat("Changed TaxRate from {0} to {1}.", o, n);
            //Other stuff here
        });
}
I like this alot as if you just need to do a quick one-off you can use short form [ n,o => _something += n ]  or the entire block, or ever call another method if needed.

I realize that I am coming late to the game on this discussion so is this recommendation has come up and been vetoed before I apologize.

rsbaker0 replied on Tuesday, January 06, 2009

skagen00:

The framework supported manner is to override PropertyHasChanged in the business object, which only is fired if a property value has changed - I realize the location is separated from the setter which may be undesirable for some, but just wanted to make sure you were aware of that.

Chris

 

An almost equivalent mechanism is to implement a business rule associated with the property ("almost" because the rule will also fire if you call CheckRules explicitly even if the property hasn't changed). However, careful implementation of the business rule logic can achieve the same results as a PropertyHasChanged override and is somewhat cleaner IMHO.

Copyright (c) Marimer LLC