I was wondering if there was a specific reason for implementing this like this in BusinessBase? I was trying to use the IsDirty value in a rule implementation, and object was still "clean" even though the property value had changed at the time the rule was executed.
protected virtual void PropertyHasChanged(string propertyName)
{
ValidationRules.CheckRules(propertyName);
MarkDirty(true);
OnPropertyChanged(propertyName);
}
This would be a (subtle) breaking change from long-established behavior.
Is there a broad concencus that this should change?
Actually, now that I look at current code, MarkDirty() is called first in 3.6. Probably in 3.5 as well, though I haven't checked there.
But this code changed quite a bit when I introduced the field manager, and added support for the WPF requirements around the PropertyChanged event.
RockfordLhotka:
Actually, now that I look at current code, MarkDirty() is called first in 3.6. Probably in 3.5 as well, though I haven't checked there.
But this code changed quite a bit when I introduced the field manager, and added support for the WPF requirements around the PropertyChanged event.
Correct. 3.5 uses the "new" style.
3.0 did it the "old" way:
Protected Overridable Sub PropertyHasChanged(ByVal propertyName As String)
ValidationRules.CheckRules(propertyName)
MarkDirty(True)
OnPropertyChanged(propertyName)
End Sub
Joe
RockfordLhotka:
This would be a (subtle) breaking change from long-established behavior.
Is there a broad concencus that this should change?
I was just wondering why it was done this way -- I could certainly override the method in the derived class in CSLA 3.0.x and do it the other way, but I didn't want to cause any unintended side effects.
Even leaving it as is, I can work around it -- it just tripped me up briefly and I thought it seemed backwards, so I thought it was worth asking about.
I can’t say why it is that way – obviously I thought
it was backwards too when I did the 3.5+ code :)
Rocky
It indeed is a subtle change, but I think the issue he brought up does seem entirely valid and I'd rather deal with the ramifications of the change (I can't imagine this really affects me) and have it work "properly".
My 2 cents
Copyright (c) Marimer LLC