I’m overriding IsSelfDirty for a particular object to return “true”, but IsDirty still returns “false”. In looking at the code in Core.BusinessBase.cs, lines 119, the IsDirty getter says the following:
Should it say the following instead?
Otherwise, I’ll have to override IsDirty as well as IsSelfDirty and implement the same code, or at least call another method.
The main problem is that during the Core.BusinessBase.cs Save method (line 118) it does an IsDirty check and ignores the IsSelfDirty.
I would assume that if an object IsSelfDirty that it would also be IsDirty as well.
I think it makes sense for the particular case Bob is explaining. Since IsSelfDirty is Overridable he should be able to Override it and get correct answers.
But what about the reverse case??
What if (in another BO) he later wants to Override IsDirty but NOT override IsSelfDirty?
Would it work if you made the code change he is requesting for the first case? Or would this case now be broken?
Joe
I am not sure of your point. Both IsDirty and IsSelfDirty currently are Overridable. I do not see that changing.
So my original question still stands - would the reverse case be an issue if Rocky made the change requested or not?
Joe
Yeah, then there’s that ugly backward compatibility issue…
IsDirty has always been overridable, and changing that would effectively break
every parent class out there, preventing a controlled migration from <3.5
into 3.5.
Rocky
From: ajj3085
[mailto:cslanet@lhotka.net]
Sent: Wednesday, March 26, 2008 1:46 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Possible IsDirty / IsSelfDirty Issue
Well my point is that IsDirty probably shouldn't be
overridable. It probably should be changed, because otherwise you end up
with the problem you state; IsDirty may return false even though IsSelfDirty
returns true.. that doesn't make sense to me why you'd want that.
Perhaps I should chime back in on this one.
For me, it’s not really a matter of a method being marked virtual or not; being virtual makes things easier should I decide to override a method for my own purposes. For example, if the decision is made to go with the status quo in this instance, I’ll probably override IsDirty in my base class to handle this scenario.
The heart of the matter is this: Should IsDirty be true if IsSelfDirty is true?
Per the default IsDirty code found in the Core\BusinessBase.cs file, what it appears to be saying is “Am I marked as dirty or are any of my child objects marked dirty?”
My thought is that the first part of the question, “am I marked dirty” should probably be answered by asking the property that knows the answer, “IsSelfDirty”.
And so the change is now in svn so IsDirty and IsValid delegate to IsSelfDirty and IsSelfValid.
I didn't change what is or is not overridable - if that happens it will be in some future version.
Copyright (c) Marimer LLC