Help! isDirty reset after call to LoadProperty<>.

bt1 posted on Wednesday, May 20, 2009

I am trying to manipulate values of the object within the object.  I would like to be able to change the value of a managed property without affecting its isDirty flag.  How can this be accomplished?

LoadProperty<> appears to call MarkClean.

I am using the isDirty flag of the IFieldData to do field level audits by using FieldManager.GetRegisteredProperties, Looping the properties and looking for dirty properties.

I am using WinForms and adjusting Properties on the object that are datetime from GMT to local once the factory method has pulled the object from the server.

rsbaker0 replied on Wednesday, May 20, 2009

This doesn't directly address the dirty flag issue, but since you mentioned auditing...

The dirty flag as implemented is unreliable for auditing IMHO. If the user changes a field, it gets marked dirty. However, if they then change it back to the original value, it still appears to be dirty since CSLA doesn't currently keep track of the "original" value of the field.

What we did, basically, is to hook OnPropertyChanging() and store the original value of any property that is changed in a cache. If you have the original value, then you can tell if the property is *really* dirty.

Biceman replied on Wednesday, May 20, 2009

I'm curious about this as well.  Ignoring the fact that a user can change a value then change it back to its original value and the field is still marked as "dirty", I am curious how to go about using managed properties for my "audit" fields.  When a field is changed by the users, I want my "audit" fields to be updated immediately.  This way they can see on the grid which rows were modified.

With un-managed properties I hooked into the "OnPropertyChanged" event and automatically updated the audit-user-name and audit-timestamp fields whenever "OnPropertyChange" fired.  Of course these two fields themselves omitted a call to "OnPropertyChanged" to avoid an infinite loop. 

During the BO load from the db, I had an "IgnorePropertyHasChanged" boolean that told the BO not to update the audit-user-name and audit-timestamp fields.

RockfordLhotka replied on Thursday, May 21, 2009

The default implementation of IsDirty is designed for performance, and it is probably not good for auditing.

You can replace the FieldData<T> implementation with other implementations. For example, you could have a FieldData<T> that maintains a list of previous values, and have its IsDirty work by comparing the current value to the most recent previous value.

If you create a custom FieldData<T> (IFieldData<T> implementation) then you'll need to create a subclass of PropertyInfo<T> to return your custom IFieldData<T> implementation type.

JoeFallon1 replied on Thursday, May 21, 2009

I have posted some sample code showing one way to subclass FieldData and PropertyInfo. It addresses this exact issue. I never put it into production though so take it for what it is worth.

Joe