Determine whether SetProperty has changed the value

Determine whether SetProperty has changed the value

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


JoshL posted on Wednesday, November 12, 2008

Often in my properties I have a need to do something only if the property value actually changed. Using the pre-3.5 CSLA syntax, it was easy to include this logic in the if statement that tests whether the value changed. In 3.5+, SetProperty handles testing whether the value needs to be modified, and doesn't tell me whether it did anything with it.

Would it be possible to return a boolean from SetProperty, indicating whether the property value was modified?

Thanks!

skagen00 replied on Wednesday, November 12, 2008

I think what you want to do is use the PropertyHasChanged override. It would fire only if a property had changed. Now, if you need to do preprocessing or something conditional based on the value you're setting _from_, then you probably have to add code in the Setter.

tetranz replied on Wednesday, November 12, 2008

This is something I miss too. I use PropertyChanged and it works fine but ... it still seems messy because you need a switch statement doing string comparisons to figure out which property has changed. It just seems like it would be cleaner to put the code in the setter like the "old" days.

tetranz replied on Wednesday, November 12, 2008

I meant to say PropertyChanged rather than PropertyHasChanged in my last post (edited on forum) but ... you can't use a switch statement if you want to use PropertyInfo.Name to avoid string constants. You need to do a if else if else if else ... etc. That seems even more messy but .... I guess there are bigger things to worry about. Smile [:)]

sergeyb replied on Wednesday, November 12, 2008

On assumption that I follow the question properly, you can still do the same style of 2.1 coding if you would like, and instead of

SetProperty(someProperty, value) you will have

 

If (ReadProperty(someProperty)!=value)

{

                SetProperty(someProperty, value);

                DoSomeOtherStuff();

}

 

There is some overhead involved with this though….

 

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

cid:_2_0648EA840648E85C001BBCB886257279
Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

 

From: tetranz [mailto:cslanet@lhotka.net]
Sent: Wednesday, November 12, 2008 5:04 PM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] Determine whether SetProperty has changed the value

 

This is something I miss too. I use PropertyHasChanged and it works fine but ... it still seems messy because you need a switch statement doing string comparisons to figure out which property has changed. It just seems like it would be cleaner to put the code in the setter like the "old" days.


tetranz replied on Wednesday, November 12, 2008

D'oh!  Thank Sergey. Somehow I didn't think of that. Smile [:)]  I suspect it has less overhead than multiple string compares every time any property changes which is what happens when I use PropertyChanged to handle changes in multiple properties.

JoshL replied on Wednesday, November 12, 2008

Right - this is probably the best approach right now, though it would be cleaner if we could avoid duplicating the value-comparison code. It's cool that Rocky handles nulls and default values in LoadProperty.

tdrake replied on Wednesday, November 12, 2008

When I done this in the past - eg need to know when the user has changes from existing or default - I've just added private memebers with the original setting and built the login in the setter...

I don't use it for undo, but more for some stupid foreign key rubbish I needed to manage while working with an existing database (an update could be a messy delete, insert grrr)

Is there a better way?

JoshL replied on Thursday, November 13, 2008

tdrake, I think you are referring to something a bit different. On a property setter, I want to avoid doing anything in the class unless the property value actually changed. This can be accomplished by comparing "value" with the backing-store value on the class. However, the normal property pattern is to then overwrite that backing store with the new value. It sounds like you have a need to keep track of the _database_ value in order to limit the columns in your update statements to only those that actually changed. To do this, you can either: - keep a second set of values on your class (via second set of fields, copy of a DTO...), or - re-select the data from the database and compare with class data prior to constructing your Update statement Hope this helps.

vdhant replied on Wednesday, November 12, 2008

That sounds like it could be a good idea, but in the mean time, couldn't you hook into the PropertyChanged for that field. This event should only be raised if the value is changed (i.e. it detects that the new value isn't the same as the old one, etc).
Cheers
Anthony

Copyright (c) Marimer LLC