The PDFx is a lightweight open source .NET library that allows developers to describe dependencies between Properties in declarative C# code. Once relationships are registered, the framework monitors property changes and ensures that the INotifyPropertyChanged.PropertyChanged event is fired for all directly and indirectly dependent properties in a very efficient way. The library is available for WPF, Silverlight, WinRT (Windows Store) and Windows Phone.

I’ve developed the PDFx as an InterKnowlogy RECESS project and published the source code and examples on codeplex.

In a series of blog posts I am going to cover the library’s most important features:

• Part I: Introduction
• Part II: Library Versions
• Part III: Getting Started
• Part IV: Using PDFx with an existing 3rd party framework
• Part V: Simple Property Dependencies
• Part VI: External Property Dependencies
• Part VII: Dynamic External Property Dependencies
• Part VIII: Collection Dependencies
• Part IX: Dynamic Collection Dependencies
• Part X: Caching
• Part XI: Smart Property Changed Notification
• Part XII: Callbacks
• Part XIII: Sanity Checks
• Part XIV: Data Delegation
• Part XV: Two Way Converters
• Part XVI: One Way Converters

Simple Data Delegation

Although the following paragraph doesn’t describe a new feature of the PDFx, it demonstrates a use case that solves a common problem developers face every day, apart from the sole monitoring of large Property Dependency networks.

The source code of the following example can be found in ViewModel ConverterDemonstrationVM which is part of the WPFSample’s source code.

More often than not, ViewModels wrap one or more instances of the Model Layer. Purists (like me) prefer to bind View-controls only to properties that come directly from the ViewModel layer rather than also to properties that come from the Model layer. This way they decouple their Model from the View and create a true MVVM architecture.
This approach, however, means that every Model-value the View eventually would like to display needs to be exposed by the ViewModel.

Let’s look at the following ViewModel implementation which wraps a Model and delegates its properties:

class ViewModel
{
	private Model Model { get; set; }

	public double MoneyInEuros
	{
		get { return Model.MoneyInEuros; }
		set { Model.MoneyInEuros = value; }
	}
}

class Model : BindableExt
{
	private double _moneyInEuros = 100;
	public double MoneyInEuros
	{
		get { return _moneyInEuros; }
		set
		{
			_moneyInEuros = value;
			NotifyPropertyChanged(() => MoneyInEuros);
		}
	}
}

The problem with this purist approach is, however, that the data might change often directly in the Model layer without having passed through the ViewModel layer.
In the example above, the Model could represent an instance from a database. A service could now monitor the database and automatically reflect any changes that are applied to the database in the Model’s instance. Obviously, the ViewModel would not know about this change unless it explicitly monitors the PropertyChanged event of the Model instance.

This problem can easily be solved by employing the PDFx:

class ViewModel : BindableExt
{
	private Model Model { get; set; }

	public double MoneyInEuros
	{
		get
		{
			Property(() => MoneyInEuros)
				.Depends(p => p.On(Model, k => k.MoneyInEuros));

			return Model.MoneyInEuros;
		}
		set { Model.MoneyInEuros = value; }
	}
}

class Model : BindableExt
{
	private double _moneyInEuros = 100;
	public double MoneyInEuros
	{
		get { return _moneyInEuros; }
		set
		{
			_moneyInEuros = value;
			NotifyPropertyChanged(() => MoneyInEuros);
		}
	}
}

In this scenario, the PDFx would automatically propagate the MoneyInEuros Property’s changes of the Model layer to the ViewModel layer.