IsSelfDirty Implementation in 3.5 Beta 2

trives posted on Tuesday, February 26, 2008

Hi Rocky,

Thanks for including the IsSelfDirty and IsSelfValid properties in the ITrackStatus interface. I have a comment about the implementation of IsSelfDirty in BusinessListBase and FieldData.

When I suggested IsSelfDirty, I was thinking that its value would indicate whether or not a business object was dirty, without considering the dirty status of any child objects. The value of IsSelfDirty would indicate a "private" dirty status instead of a "collective" dirty status that the IsDirty property provides.

The original post gave an example for just BusinessBase, but I was thinking the implementation for BusinessListBase would be along the lines of:

bool Core.ITrackStatus.IsSelfDirty
{
get { return false; }
}

This is because an editable collection doesn't normally have any editable properties of its own. There is no private _isDirty field. So, it's private state is never dirty.

For FieldData, I was thinking the implementation would be similar to that of BusinessBase since FieldData has an _isDirty field.

public bool IsSelfDirty
{
get { return _isDirty; }
}

Hopefully, this clarifies the distinction between IsSelfDirty and IsDirty that was in my head.

Also, thank you for considering the suggestion about using the provider pattern for object level authorization. I understand the time constraints for the book prevent you from doing anything in 3.5, and I agree that a good design for authorization needs a lot of thought and analysis.

Tim

RockfordLhotka replied on Tuesday, February 26, 2008

Thanks for the comments.

I think the FieldData implementation is correct as it is. If the FieldData contains a complex object it should act as a pass-through to that underlying object. The local _isDirty value is really there only for managing primitive values.

I'm not as confident on BLB, but I think the current implementation is correct. Certainly if you've added or deleted items the list should be considered dirty, because the state of the list is its contents. And following that train of thought (that its state is its contents) then a changed child also means the list has been changed.

trives replied on Tuesday, February 26, 2008

Okay. Would it make sense and is it feasible to add a protected, virtual IsSelfDirty in BusinessListBase, like IsSelfValid? This way, I could override IsSelfDirty.

If not, I guess I can just redefine the explicit implementation of IsSelfDirty in a custom base class that inherits from BusinessListBase. Somehow that doesn't seem very proper to me, but it seems to work.

rasupit replied on Tuesday, February 26, 2008

I can concur with Rocky on this that the IsSelfDirty is working correctly. Here is the unit test that I ran when testing of my generated code.

            Project p = GetSUT();
            p.Resources[0].Role = 6;
            Assert.IsTrue(p.IsDirty);
            Assert.IsFalse(p.IsSelfDirty);
            Assert.IsTrue(p.Resources[0].IsDirty);
            Assert.IsFalse(p.Resources[1].IsDirty);
            p = p.Save();

            Assert.IsFalse(p.IsDirty);
            Assert.AreEqual(6, p.Resources[0].Role);

            p = Project.GetProject(id);
            Assert.IsFalse(p.IsDirty);
            Assert.AreEqual(6, p.Resources[0].Role);

JoeFallon1 replied on Wednesday, February 27, 2008

I agree with Rocky too.

Note: the comments for IsSelfDirty and IsSelfValid in the Beta are not reflective of what is coded.

I assume they are on the TODO list.

Joe

RockfordLhotka replied on Wednesday, February 27, 2008

JoeFallon1:

I assume they are on the TODO list.

Oh, make no such assumptions. I'm sure there's a lot of cleanup to do, and I'm not aware of it all, so please point out what you find.