Taking it from where we left off at the previous post on this series, let’s improve our DynamicDtoDecorator so it handles raising PropertyChanged events for properties that depend on other properties.

First, let’s revisit our InvoiceItemViewModel class:

public class InvoiceItemViewModel
{
    public string ProductName { get; set; }
    public string Category { get; set; }
    public decimal Price { get; set; }
    public int Quantity { get; set; }
    public decimal Total => Price * Quantity;
}

As far as the UI is concerned, whenever either Price or Quantity changes on that object, the display of Total should refresh accordingly. In other words, Total depends on both Price and Quantity. I wanted to represent this dependency decorating the property with an attribute in the following manner:

[DependsOnAttribute("Price, Quantity")]public decimal Total => Price * Quantity;

Let’s look at the changes needed to implement that behavior. First, the implementation of DependsOnAttribute:

public class DependsOnAttribute : Attribute
{
	public string PropertyNames { get; set; }

	public DependsOnAttribute(string propertyNames)
	{
		PropertyNames = propertyNames;
	}
}

Definitely nothing special there. Next, changes to the DynamicDtoDecorator. Starting with a property to keep a dictionary of property dependencies (the key is the name of the property that has dependencies and the value is a list of properties that it depends on):
readonly Dictionary<string, IEnumerable<string>> _propertyDependencies = new Dictionary<string, IEnumerable<string>>();
We then change the RegisterProperties method so it verifies whether the property its registering has dependencies, and if so, it calls out the RegisterPropertyDependencies method:

protected virtual void RegisterProperties(object dto)
{
    dto.GetType()
        .GetProperties(BindingFlags.Public | BindingFlags.Instance)
        .ToList()
        .ForEach(prop =>
        {
            object[] notIndexedProperty = null;
            Func valueGetter = () => prop.GetValue(dto, notIndexedProperty);
            Action valueSetter = newValue => prop.SetValue(dto, newValue, notIndexedProperty);
            Register(prop.Name, valueGetter, valueSetter);

            var dependsOn = prop.GetCustomAttributes(true).OfType().SingleOrDefault();
            if (dependsOn != null)
            {
                RegisterPropertyDependencies(prop.Name, Array.ConvertAll(dependsOn.PropertyNames.Split(','), d => d.Trim()));
            }
        });
}

Here’s the implementation of RegisterPropertyDependencies:

public void RegisterPropertyDependencies(string property, string[] dependencies)
{
	_propertyDependencies.Add(property, dependencies);
}

We then have to change the SetProperty method to make sure we raise PropertyChanged for properties that depend on the property being changed:

public virtual void SetProperty(string propertyName, dynamic value)
{
	if (!_members.ContainsKey(propertyName))
		throw new InvalidOperationException({0}#x22;Unregistered member: {propertyName}");

	if (_members[propertyName].Get() == value) return;

	_members[propertyName].Set(value);
	RaisePropertyChanged(propertyName);
	RaisePropertyChangedForDependentsOn(propertyName);
}

Here’s the implementation for the RaisePropertyChangedForDependentsOn method:

void RaisePropertyChangedForDependentsOn(string propertyThatWasChanged)
{
    _propertyDependencies.ForEach(dependentProperty =>
    {
        var dependableProperties = dependentProperty.Value;
        if (!dependableProperties.Contains(propertyThatWasChanged)) return;

        var dependentPropertyName = dependentProperty.Key;
        RaisePropertyChanged(dependentPropertyName);
    });
}

The code simply looks through the registered properties that have dependencies and raise the event as appropriate.

This pretty much wraps up all the main pieces for getting rid of direct implementation of INotifiyPropertyChanged in ViewModels by using the C# Dynamic features. I’ll be keeping the latest version of the code in this repository, so feel free to check it out. I’ll be writing new posts for other improvements I’ve added to the decorator and you might find useful. Stay tuned!

In case you missed any part of this series, here are the links to Part 1, Part 2, Part 3 and Part 4.

With what we wrote up to the previous post, we should be able to write the following code:

var viewModel = new InvoiceItemViewModel { ProductName = “Some value" };

dynamic decorator = new DynamicDtoDecorator(viewModel);

The next step is to enable access to the properties through the decorator, like so:

decorator.ProductName = “Some new value”;
Console.WriteLine(decorator.ProductName);

Since the decorator variable above has been declared as dynamic, the compiler won’t complain about the DynamicDtoDecorator not having such a thing as a ProductName property. However, during runtime, the code will blow up when it tries to access that property. Here’s what we need to do to the DynamicDtoDecorator class so it knows how to set a value to a dynamic property:

public override bool TrySetMember(SetMemberBinder binder, object value)
{
    SetProperty(binder.Name, value);
    return true;
}

public virtual void SetProperty(string propertyName, dynamic value)
{
    if (!_members.ContainsKey(propertyName))
        throw new InvalidOperationException({0}#x22;Unregistered member: {propertyName}");
    if (_members[propertyName].Get() == value) return;
    
    _members[propertyName].Set(value);
    RaisePropertyChanged(propertyName);
}

Our DynamicDtoDecorator class inherits from DynamicObject, which provides a TrySetMember method: this method gets called during runtime whenever we try to set a member on the object. Its SetMemberBinder parameter has a Name property, which gives us the name of the member we’re trying to set (in earlier example, that’d be the “ProductName” property). The method also takes in the value we’re trying to set the member to. Finally, the method is supposed to return true or false in order to indicate whether it could successfully set the value or not.

I’ve created a SetProperty method, which is called by the TrySetMember method, just to keep things more organized. This method performs a some simple validation (making sure the given property name is registered within the decorator), sets the value on the property using our PropertyAccessor, and calls RaisePropertyChanged.

The code that allows us to get the value of a property is very similar:

public override bool TryGetMember(GetMemberBinder binder, out object result)
{
    if (_members.ContainsKey(binder.Name))
    {
        var propertyValue = _members[binder.Name];
        result = propertyValue.Get();
        return true;
    }
    result = null;
    return false;
}

So, whenever we try to get the value of a dynamic property, a TryGetMember method is called. It takes in a GetMemberBinder, which gives us the name of the member we’re trying to access, and it also takes in an out parameter to which we set what value we want returned out of that operation. The method itself needs to return a boolean indicating whether or not the method succeeded.

That’s it! The most basic implementation of our decorator is ready: we can instantiate it passing in a ViewModel or other type of DTO, set it to the DataContext in WPF visual elements, and use DataBinding. The data displays on the UI, and should values in properties change, the UI should be updated to reflect the change.

So far, what we’re calling a decorator is really a proxy, since it doesn’t really add much functionality to the underlying object. However, once I got to this point, I started seeing other things I could use this approach for, and the class really became a decorator. But more on that on some other upcoming posts. We’re not done with this series yet!

On this part of this series, we start looking at the DynamicDtoDecorator class. We begin by seeing how it takes in the object that it decorates and how it figures out what the public instance properties in the decorated object are, and how to access them. We’ll be seeing how we use the PropertyAccessor class created in the previous installment of this series.

Our DynamicDtoDecorator! We start like this:

public class DynamicDtoDecorator : DynamicObject, INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged = (sender, args) => { };

	void RaisePropertyChanged(string propertyName)
    {
        PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

The class inherits from DynamicObject so we can get some dynamic support for free. It also implements INotifyPropertyChanged. “But aren’t we trying to get rid of INotifyPropertyChanged?”. Yes, we’re trying to get rid of it in our ViewModels, but we still need it somewhere for WPF binding to work.

Next, we have a private field to store the DTO (Data Transfer Object) that the class decorates. The DTO is passed into the class constructor

readonly object _dto;

public DynamicDtoDecorator(object dto)
{
    _dto = dto;
    RegisterProperties();
}

Notice that the constructor calls out to a RegisterProperties method. Let’s see what that method looks like:

protected void RegisterProperties()
{
    _dto.GetType()
        .GetProperties(BindingFlags.Public | BindingFlags.Instance)
        .ToList()
        .ForEach(prop =>
        {
            object[] notIndexedProperty = null;
            Func valueGetter = () => prop.GetValue(dto, notIndexedProperty);
            Action valueSetter = newValue => prop.SetValue(dto, newValue, notIndexedProperty);
            Register(prop.Name, valueGetter, valueSetter);
        });
}

The method looks for any public instance property on the DTO type, creates getter and setter delegates, and register them with in the decorator. If you’ve been following my series on this topic, you’ll remember my explanation on a PropertyAccessor class I created in the previous installment, so you can already think how those getter/setter delegates are going to be used, right? Well, alright, I forget things all the time, too, so let’s see what that Register method looks like:

public void Register(string propertyName, Func valueGetter, Action valueSetter)
{
    var fullPropertyName = propertyName;

    if (_members.ContainsKey(fullPropertyName))
       return;

    dynamic initialValue = valueGetter.Invoke();
    var propertyValue = new PropertyAccessor(propertyName, valueGetter, valueSetter, initialValue);
    _members.Add(fullPropertyName, propertyValue);
}

Nothing special going on there. The _members field is defined in the class like this:

readonly Dictionary<string, PropertyAccessor> _members = new Dictionary<string, PropertyAccessor>();

Just a pretty Dictionary, that’s all.

Right now, our decorator knows what it needs to access on the decorated object, and how to access it. In the next part we explorer how this is going to be exposed to the outside world. Stay tuned!

el;In Part 1, I mentioned I wanted to decorate a ViewModel with “notify property changed” behavior, so I could keep my ViewModel as clean as possible. In this part I’ll go over how the properties on the decorated object are going to be accessed.

Say we have the following code:

dynamic viewModel = new DtoDecorator(new InvoiceItemViewModel());
viewModel.ProductName = “My great product”;
Console.WriteLine(viewModel.ProductName);

A “non-dynamic” implementation of the decorator could look somewhat like this (disregard the implementation of INotifyPropertyChanged for now):

public class DtoDecorator
{
    InvoiceItemViewModel _decoratedViewModel;

    public DtoDecorator(InvoiceItemViewModel viewModel)
    {
	_decoratedViewModel = viewModel;
    }

    public string ProductName 
    {
        get 
        {
            return _decoratedViewModel.ProductName;
        }
        set
		{
			_decoratedViewModel.ProductName = value;
		}
    }
}

The important aspect in the code above is that the decorator has to be able to access properties on the decorated object. In order to come up with a generic way to do that, I’ve created a PropertyAccessor class, designed to get/set value on a property.

The PropertyAccessor class uses a Func delegate to do the “get” and an Action delegate to do the “set”, like so:

var viewModel = new InvoiceItemViewModel { ProductName = “Some value" };

var getter = new Func(() => viewModel.ProductName);
var setter = new Action(value => viewModel.ProductName = value.ToString());
_propertyAccessor = new PropertyAccessor("ProductName", getter, setter, initialValue);

With that in place, we can get or set that property like so:

_propertyAccessor.Set(“New value”);
var currentValue = _propertyAccessor.Get();

This is what the PropertyAccessor class looks like:

public class PropertyAccessor
{
    readonly Func _getter;
    readonly Action _setter;

    public PropertyAccessor(string propertyName, 
        Func getter, 
        Action setter,
        dynamic initialValue)
    {
        PropertyName = propertyName;
        _getter = getter;
        _setter = setter;
        InitialValue = initialValue;
        CurrentValue = initialValue;
    }

    public string PropertyName { get; }
    public dynamic InitialValue { get; }
    public dynamic CurrentValue { get; private set; }

    public bool Changed => InitialValue != CurrentValue;

    public dynamic Get()
    {
        return _getter.Invoke();
    }

    public void Set(dynamic value)
    {
        _setter.Invoke(value);
        CurrentValue = value;
    }
}

Notice we also keep track of initial and current values so we can do some basic change tracking, which comes in handy.

Now that we have a generic way to get/set value on properties of an object, the next step will be to look at that decorator class. Coming up next!

Continuing on with our series on using the dynamic features of C#, let me share how I’ve used it to address an issue that bugged me several years ago.

When creating ViewModels for WPF applications, I got fed up with having to implement INotifyPropertyChanged and pollute the classes like this:

public class InvoiceItemViewModel : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChanged(string propertyName)
        {
            PropertyChanged.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
private string _productName;
public string ProductName
        {
            get { return _productName; }
            set
            {
                if (_productName != value)
                {
                    _productName = value;
                    OnPropertyChanged("ProductName");
                }
            }
        }
    }

I didn’t want to see 12 lines in the code for each property exposed. Instead, I wanted to have something like this:

    public class InvoiceItemViewModel
    {
        public string ProductName { get; set; }
        public string Category { get; set; }
        public decimal Price { get; set; }
        public int Quantity { get; set; }
        public decimal Total => Price * Quantity;
    }

That’s as simple as the class can get. That’s how I wanted my ViewModels to look like. Notice it doesn’t even inherit from any baseclass, and it doesn’t have any attributes decorating the class (the way I also did at some point when using IL weaving tools such as PostSharp).

WPF databinding is late-bound, so as long as the property exists on the object during runtime, everything works just fine. When it comes to changing data in the UI and having WPF broadcast the message that the some properties have changed, well, the ViewModel needs to raise the PropertyChanged event. So, I decided to go ahead and create a DynamicDecorator class, which would decorate my ViewModels with the “notify property changed” behavior.

Before assigning my ViewModel to the UI’s DataContext property, I’d use the decorator, somewhat like this:

DataContext = new DynamicDecorator(new InvoiceItemViewModel());

In reality, I had an interceptor in my repository that’d do the decoration part automatically for me, but that’s beyond the point here.

In other words, say I had the following code somewhere in my WPF app:

var item = GetItem();
item.ProductName = “Banana”;

The implementation of GetItem could look like this:

InvoiceItemViewModel GetItem()
{
    return new InvoiceItemViewModel();   
}

But then again, since WPF’s databinding is late-bound, GetItem, in my case, looked something like this:

dynamic GetItem()
{
    return new DynamicDtoDecorator(new InvoiceItemViewModel());
}

The DynamicDtoDecorator simply intercepts access to the properties on the ViewModel it decorates, and it raises PropertyChanged when appropriate. I’ll show and explain the implementation of that class on my next post.

Wondering why the class is named Decorator, instead of Proxy? That’s also coming up in another post. Stay tuned!