Determine whether SetProperty has changed the valueDetermine 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.
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
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.
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
AnthonyCopyright (c) Marimer LLC