It’s often very useful to know when an object we are editing has Changed. The most iconic example is the “*” that used to appear next to the title of Word documents once you’d made the first change no matter how small. It’s not an unusual request that a “Save” button be disabled until the User has made a savable change. This is often referred to as an object being Dirty.
This article is part of a series about useful MVVM friendly features for your data objects and favoring composition over inheritance. You can read the other parts:
Dirty Aware
Now that we’ve introduced the idea of Property Change Behaviors, it’s easy for us to flag an object as having changed when we set any property value. Let’s refer back to the BBGrill object in the Metro BBQ sample application. I find it’s useful to standardize the HasChanges/Dirty state using an interface.
/// <summary>
/// Capable of storing and notifying Dirty/HasChanged state
/// </summary>
public interface IDirtyAware
{
bool IsDirty { get; set; }
bool SuspendChangeNotification { get; set; }
}
We can now author a new IPropertyChangedBehavior that deals with IDirtyAware instances and sets their IsDirty flag to true whenever a property value changes.
public class DirtyPropertyBehavior : IPropertyChangedBehavior
{
/// <summary>
///
/// </summary>
/// <param name="owningInstance"></param>
public DirtyPropertyBehavior(IDirtyAware owningInstance)
: this(owningInstance, new List<string>() {"IsDirty"})
{
}
/// <summary>
///
/// </summary>
/// <param name="owningInstance"></param>
/// <param name="exclusions"></param>
public DirtyPropertyBehavior(IDirtyAware owningInstance, List<string> exclusions)
{
_owner = owningInstance;
_propertyExclusions = exclusions;
}
IDirtyAware _owner;
List<string> _propertyExclusions;
/// <summary>
///
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="owningInstance"></param>
/// <param name="oldVal"></param>
/// <param name="newVal"></param>
/// <param name="propertyName"></param>
/// <returns></returns>
public bool PropertyChanged<T>(object owningInstance, T oldVal, T newVal, string propertyName)
{
if (!Object.Equals(oldVal, newVal)
&& !_propertyExclusions.Contains(propertyName)
&& !_owner.SuspendChangeNotification)
{
_owner.IsDirty = true;
}
return true;
}
}
Note that we can easily provide the ability to exclude certain properties from setting IsDirty, which is very useful for the IsDirty property itself.
Obviously we could put this functionality right inside the property setters but we want to make it easy to add/remove behaviors to objects.
Dirty Grill
Going back to the Metro BBQ sample application, I can now make BBQGrill implement IDirtyAware and also use the DirtyPropertyBehavior to flag when any change has been made.
public class BBQGrill : BindableType, INotifyDataErrorInfo, IDirtyAware
{
public BBQGrill()
{
_changeBehaviors.Add(new DirtyPropertyBehavior(this));
Now, this is useful as we can key business logic off of the IsDirty property, however we can also bind to it in the UI which is just as useful. Recall the Ideal Grill survey page from Metro BBQ. We wanted to only enable the Save and Rest buttons once the user had made changes. Now it’s easy to do so:
<Button Content="Submit" Margin="10,0,10,0" IsEnabled="{Binding Grill.IsDirty}" />
<Button Content="Reset" Margin="10,0,10,0" IsEnabled="{Binding Grill.IsDirty}" />
This gives us the effect that we want in the UI for any property with extremely little code.
Screen default state:
After changing one property:
Because of the way we structured Property Change Behaviors we just got a Binding-friendly “is dirty” behavior on all properties of the BBQGrill object. Once we wrote the DirtyPropertyBehavior we got this essentially for free on all properties without writing extra code for every property.
Suspend Notifications
You may already be thinking of situations where you’d like to temporarily turn this property behavior off. For example, you might be populating BBQGrill object values from a WCF service and obviously invoking property setters in that situation should not instantly mark the object as Dirty or this feature won’t be very useful. You may have noticed that the IDirtyAware interface included a SuspendChangeNotification property and that the DirtyPropertyBehavior pays attention to this and does not set IsDirty when SuspendChangeNotification is set to true. This solves the re-entrant problem but we can do a little better in terms of the developer experience around this code using a context class.
/// <summary>
/// Enable nice using(){} semantics for setting property values without firing Dirty state behaviors
/// </summary>
public class SuspendDirtyContext : IDisposable
{
public SuspendDirtyContext(IDirtyAware target): this( new List<IDirtyAware> { target } )
{
}
public SuspendDirtyContext(IEnumerable<IDirtyAware> targets)
{
_targets = targets;
int index = 0;
_targets.ForEach(d =>
{
_previousValues[index] = d.SuspendChangeNotification;
d.SuspendChangeNotification = true;
++index;
});
_previousValues = new bool[_targets.Count()];
}
IEnumerable<IDirtyAware> _targets;
bool[] _previousValues;
public void Dispose()
{
int index = 0;
_targets.ForEach(d =>
{
d.SuspendChangeNotification = _previousValues[index];
++index;
});
}
}
In C#, classes that implement IDisposable can be used in using() blocks. While we’re not really getting rid of any resources here the syntactical sugar is too good to pass up. This SuspendDirtyContext allows us to write nice readable code like the following:
var bbqGrill = new BBQGrill();
using (var ctx = new SuspendDirtyContext(bbqGrill))
{
//... set initial values
}
The using() block in C# winds up creating try/catch/finally semantics in IL, so even if something causes an exception to be thrown our object state won’t be wonky outside of this scope. As you can see the SuspendDirtyContext can also handle more than one IDirtyAware instance.
Conclusion
Knowing when a user has made a change to a data entity through the UI is a commonly requested and useful feature, and implementing it can be pretty easy with the right design of your data entities. Using the Composition approach makes it very easy to turn this feature on and off for different objects or even different instances of the same type depending on your needs.
There are still situations that can be easily supported using the same techniques we’ve already demonstrated and these will be explored in the following articles.
Subscribe