//InterKnowlogy/ Blogs

Session 12 of the WinRT Development Class – Hackathon Results and Prize Giveaways (Links to All Class Materials & Recordings)

Danny Warren — Wed, 05 Jun 2013 21:01:12 +0000

THAT WAS AWESOME!!! We had some killer apps show up to this and I just wanted to say thanks to everyone who showed attended any of our classes. I am very pleased at how well everyone performed. We had some rough patches, but I’d say this class was a huge success! I’d love to hear what you thought about it! What can we do to improve it?

Special Thanks

First a huge thanks to Kim Schmidt who, despite many struggles during the course of this class, has been an outstanding support. She secured our location and really got this class up and running. So again, a huge thanks to her! Also, vNext_OC has been critical in this event. We want to thank all those who have helped organize the user group and keep it running! Great job! We want to give a special thanks to our hosts Saddleback College. They were tremendous hosts and helped us a ton! And a huge thanks to Microsoft for sponsoring dinner each night. It was delicious! Of course we wouldn’t be anywhere with out our prizes so another giant thanks to Microsoft and Nokia DVLUP who sponsored all of the cool prizes and giveaways! Kevin and I have feel honored and privileged to have worked with such amazing sponsors, leaders, and attendees! Thank you everyone for your participation!

Overview Of Sessions

Blog Post Links (posts contain links to recorded sessions 2-11):

Development Environment for Windows 8

Session 1 & 2 of the WinRT Development Class – Introduction, XAML, and WinRT’s Control Framework

Session 3 of the WinRT Development Class – App Lifecycle and Navigation

Session 4 of the WinRT Development Class – Async/Await, WinRT API, and Security

Session 5 of the WinRT Development Class – Search and Settings

Session 6 of the WinRT Development Class – Share Contract

WinRT Development Class – Spring Break Update

Session 7 of the WinRT Development Class – Live Tiles and Background Tasks

Session 8 of the WinRT Development Class – Orientation And Near Field Communication

Session 9 of the WinRT Development Class – Intro to Model-View-ViewModel (MVVM)

Session 10 of the WinRT Development Class – InterKnowlogy’s WinRT MVVM Framework Part I/II

Session 11 of the WinRT Development Class – InterKnowlogy’s WinRT MVVM Framework Part II/II

MeetUp Links:

Session 11 of the WinRT Development Class – InterKnowlogy’s WinRT MVVM Framework Part II/II

Danny Warren — Wed, 05 Jun 2013 20:54:04 +0000

That’s a wrap! All code sessions are now complete! Awesome! Now to see the Hackathon results!

Session Resources

Overview Of Sessions

The links below lead you to Meetup Events where you can RSVP. We look forward to seeing you at our next session!

PDFX: First Thoughts

mikebev — Wed, 29 May 2013 22:29:30 +0000

Quick poll: raise your hand if you

A) are a developer, and

B) have ever had to write an application with a complex graph of property dependencies.

Keep your hand up if your solution to that complex graph involved some combination of complicated property update methods, a fragile web of events and handlers wired up between properties, wailing and gnashing of teeth, or all of the above.

Brothers and sisters, put down your hands and download your deliverance: fellow InterKnowlogist Kevin Stumpf recently posted a blog series on his new Property Dependency Framework for .NET applications, PDFx. I’ve spent the last week or so implementing it for (my) first time on a project here at InterKnowlogy, and wanted to whip up a quick post on my first impressions. Since a code snippet is worth a thousand words, let’s lead with a quick example:

//Depends on value of Properties B1 and B2, and returns their summation.
public int A1
{
     get
     {
          Property(() => A1)
                  .Depends(p => p.On(() => B1)
                  .AndOn(() => B2));
          //"Property A1 depends on B1 and on B2". How cool is that?
		
          return B1 + B2;
     }
}

Yep, it’s really that simple. Fluent interface, stupid-simple declaration, and all that’s required is to inherit your model objects from a Bindable base class provided by the framework. And the best part? It all just… works, like magic. In our example above, any time B1 or B2 change, A1 is automatically reevaluated, as are any other properties dependent upon its value. There’s all sorts of great documentation on Kevin’s blog, including great info on advanced features like external property dependencies, collection dependencies (very nifty), and caching. Bottom line: if you develop .NET applications in any capacity of even moderate complexity, take five minutes to grab the code from CodePlex and check out the documentation, and if you’re not completely satisfied, I’ll send you a case of Kölsch as a way of saying entschuldigung.*

*German for “sorry”, in honor of Herr Stumpf’s forefathers.
*Not an actual offer.

PDFx – Property Dependency Framework – Part XVI, One Way Converters

Kevin Stumpf — Fri, 17 May 2013 17:09:30 +0000

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:

One Way Converters

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.

In Two Way Converters I argue that value converters should be used exclusively to convert business domain data to UI specific data rather than to solely transform business domain data. I also showed how the PDFx can be employed to render two-way value converters, which convert domain data, redundant. The very same pattern can be applied to mimic the behavior of one way value converters in your ViewModel:

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

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

			if (Model.MoneyInEuros < 0)
			{
				return "Not too much";
			}

			if (Model.MoneyInEuros < 1000)
			{
				return "A Little";
			}

			if (Model.MoneyInEuros < 10000)
			{
				return "Quite some";
			}

			return "A Lot";
		}
	}
}

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

In this scenario, the PDFx ensures that the MoneyQuantification Property gets reevaluated whenever the Model’s MoneyInEuros Property changes.

PDFx – Property Dependency Framework – Part XV, Two Way Converters

Kevin Stumpf — Fri, 17 May 2013 17:08:00 +0000

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:

Two Way Converters

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

Oftentimes developers use value converters to transform domain-specific data into other domain-specific data (e.g. convert a money value from one currency to another), and thereby scatter conversion business logic throughout the project by implementing it in various different converters (that technically belong to the UI layer). The reason for this typical behavior is simple: comfort. value converters get automatically reevaluated as soon as the input data changes and therefore they are an easy tool to display up-to-date transformed data in the UI.
From my point of view, however, value converters should be used mainly to convert domain-specific data to UI-specific data (e.g. convert a bool from the ViewModel to a Visibility for the View). All the massaged data, which eventually ends up in the View, should be exposed by the ViewModel. This way a new View could easily be plugged into the existing ViewModel and business logic is executed before it reaches the View layer.

The PDFx allows you to enjoy the comfort of value converters (automatic reevaluation) within your ViewModels.

As explained in Data Delegation, the PDFx can be used to expose Model-data in the ViewModel.
The implementation of the MoneyInUSD-Property shows that the data doesn’t have to be delegated as is but can easily be transformed on the fly:

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

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

			return Model.MoneyInEuros * 1.3;
		}
		set { Model.MoneyInEuros = value / 1.3; }
	}
}

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

In this scenario, the PDFx ensures that the MoneyInUSD Property gets reevaluated whenever the Model’s MoneyInEuros Property changes.

PDFx – Property Dependency Framework – Part XIV, Data Delegation

Kevin Stumpf — Fri, 17 May 2013 17:05:40 +0000

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:

Simple Data Delegation

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.

PDFx – Property Dependency Framework – Part XIII, Sanity Checks

Kevin Stumpf — Fri, 17 May 2013 17:04:01 +0000

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:

Sanity Checks

Please refer to Library Versions to find out whether your platform specific PDFx version supports Sanity Checks.

In Debug mode, the PDFx performs certain resource expensive Sanity Checks that try to capture typical developer mistakes that are not caught at compile time.

Both the BindableExt’s Property and CachedValue methods ensure that the Property that is being pointed to in the first method parameter equals the Property from which either method is being called.

In the following example, the PDFx notices upon first access of the properties DependentPropertyMistake and CachedPropertyMistake that the way they use the PDFx is incorrect.

class WrongPDFXUsageDemonstration : BindableExt
{
	private int _inputValue;
	public int InputValue
	{
		get { return _inputValue; }
		set
		{
			_inputValue = value;
			NotifyPropertyChanged(() => InputValue);
		}
	}

	public int DependentPropertyMistake
	{
		get
		{
			Property(() => InputValue) //Should point to DependentPropertyMistake
				.Depends(p => p.On(() => InputValue));

			return InputValue*2;
		}
	}

	public int DependentPropertyProper
	{
		get
		{
			Property(() => DependentPropertyProper)
				.Depends(p => p.On(() => InputValue));

			return InputValue * 2;
		}
	}

	public int CachedPropertyMistake
	{
		get
		{
			return CachedValue(() => InputValue, () => InputValue * 5);
			//Should point to CachedPropertyMistake
		}
	}

	public int CachedPropertyProper
	{
		get
		{
			return CachedValue(() => CachedPropertyProper, () => InputValue * 5);
		}
	}
}

PDFx – Property Dependency Framework – Part XII, Callbacks

Kevin Stumpf — Fri, 17 May 2013 17:01:16 +0000

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:

Callbacks

When a source property changes, the PDFx allows you not only to automatically fire the PropertyChanged event for dependent properties, but also to execute callbacks in numerous scenarios.

The registration API for callbacks is not declarative, as the Property Dependency Registration API is, but rather imperative. Furthermore, the registration should not take place within a Property Getter but rather within a dedicated Registration method, as the following examples show.

Callbacks on Property Changes

The following example demonstrates how you can register Callbacks for normal Property Changes:

class SimpleCallbackExample : BindableExt
{
	public SimpleCallbackExample()
	{
		RegisterCallbacks();
	}

	private void RegisterCallbacks()
	{
		RegisterCallbackDependency(Property1, OnProperty1Changed);
	}

	private void OnProperty1Changed()
	{
		Debug.WriteLine("Property1 has changed!");
	}

	private AnyType _property1;
	public AnyType Property1
	{
		get { return _property1; }
		set
		{
			_property1 = value;
			NotifyPropertyChanged(() => Property1);
		}
	}
}

The used overload of RegisterCallbackDependency expects you to pass in the owner of a property as the first parameter, a delegate that points to the Property that is to be monitored as the second parameter and finally a pointer to the callback that is supposed to be executed when the Property changes.

In the example above, OnProperty1Changed will be executed by the PDFx whenever Property1 changes.

Callbacks on Objects

The following example demonstrates how you can register one callback for all Property Changes of an object:

class ObjectCallbackExample : BindableExt
{
	public ObjectCallbackExample()
	{
		RegisterCallbacks();
	}

	private void RegisterCallbacks()
	{
		RegisterCallbackDependency(this, OnAnyPropertyChanged);
	}

	private void OnAnyPropertyChanged()
	{
		Debug.WriteLine("Any Property has changed!");
	}

	private AnyType _property1;
	public AnyType Property1
	{
		get { return _property1; }
		set
		{
			_property1 = value;
			NotifyPropertyChanged(() => Property1);
		}
	}

	private AnyType _property2;
	public AnyType Property2
	{
		get { return _property2; }
		set
		{
			_property2 = value;
			NotifyPropertyChanged(() => Property2);
		}
	}
}

The used overload of RegisterCallbackDependency expects you to pass in a property owner that is to be monitored as the first parameter and a pointer to the callback that is supposed to be executed when any Property changes as the second parameter.

In the example above, OnAnyPropertyChanged will be executed by the PDFx whenever Property1 or Property2 changes.

Callbacks on Collections’ children

The PDFx also allows you to register callbacks that are to be fired when a specific property of an ObservableCollection’s child changes:

class CollectionPropertyCallbackExample : BindableExt
{
	private DependencyFrameworkObservableCollection _children 
		= new DependencyFrameworkObservableCollection();

	public CollectionPropertyCallbackExample()
	{
		RegisterCallbacks();
	}

	private void RegisterCallbacks()
	{
		RegisterCallbackDependency(_children, k => k.Property1, OnCollectionChildPropertyChanged);
	}

	private void OnCollectionChildPropertyChanged()
	{
		Debug.WriteLine("Property1 of a child has changed!");
	}

	private class Child : BindableExt
	{
		private AnyType _property1;
		public AnyType Property1
		{
			get { return _property1; }
			set
			{
				_property1 = value;
				NotifyPropertyChanged(() => Property1);
			}
		}
	}
}

The first parameter of this RegisterCallbackDependency overload expects the collection that is to be monitored. The second parameter is to point to the Children’s Property that is of interest. The third parameter finally points to the callback that is to be executed.

In the example above, the method OnCollectionChildPropertyChanged will get fired whenever Property1 of any child changes.

Callbacks on entire Collections

The PDFx also allows to register callbacks that get executed whenever any child’s property changes or a child gets added or removed:

class CollectionCallbackExample : BindableExt
{
	private DependencyFrameworkObservableCollection _children
		= new DependencyFrameworkObservableCollection();

	public CollectionCallbackExample()
	{
		RegisterCallbacks();
	}

	private void RegisterCallbacks()
	{
		RegisterCallbackDependency(_children, OnCollectionChanged);
	}

	private void OnCollectionChanged()
	{
		Debug.WriteLine("Collection has changed!");
	}

	private class Child : BindableExt
	{
		private AnyType _property1;
		public AnyType Property1
		{
			get { return _property1; }
			set
			{
				_property1 = value;
				NotifyPropertyChanged(() => Property1);
			}
		}

		private AnyType _property2;
		public AnyType Property2
		{
			get { return _property2; }
			set
			{
				_property2 = value;
				NotifyPropertyChanged(() => Property2);
			}
		}
	}
}

The first parameter of the used RegisterCallbackDependency overload expects the ObservableCollection that is to be monitored. The second parameter points to the callback.

PDFx will automatically execute the callback whenever any property of a child changes and whenever the collection itself is modified either by adding or by removing a child.

Deferred Callbacks

Please refer to Library Versions to find out whether the platform specific version of PDFx that you are using supports “Deferred Callbacks”

All the RegisterCallbackDependency overloads that are described in the paragraphs above are also available with the method RegisterDeferredCallbackDependency that allows you to register deferred callbacks.
If you register deferred callbacks, the execution of the callback is deferred by a certain amount of time (by default 100ms). Furthermore, if the callback trigger (such as a Property change) fires again before the wait time threshold has passed, the wait timer is reset. This feature gets especially useful when your callback is rather resource expensive and the underlying trigger might fire multiple times in a row.

Let’s look at the following example:

class SimpleCallbackExample : BindableExt
{
	public SimpleCallbackExample()
	{
		RegisterCallbacks();
	}

	private void RegisterCallbacks()
	{
		RegisterDeferredCallbackDependency(this, k => SliderValue, SubmitDataToServer);
	}

	private void SubmitDataToServer()
	{
		Debug.WriteLine("Expensive call to submit data to server...");
	}

	private int _sliderValue;
	public int SliderValue
	{
		get { return _sliderValue; }
		set
		{
			_sliderValue = value;
			NotifyPropertyChanged(() => SliderValue);
		}
	}
}

In the example above, the SliderValue property could be bound to a slider. The requirement is to submit the slider’s new value to a server as soon as the user changes value. However, since a server call is rather expensive, the value should not be submitted while the user is still changing the value but rather as soon as the user finishes the change operation.
Such a requirement can easily be implemented by employing deferred callbacks as shown above.

Extensive Example

Please refer to WPFSample’s CallbacksDemonstrationVM to explore an example that makes heavy usage of the callback features.

PDFx – Property Dependency Framework – Part XI, Smart Property Changed Notification

Kevin Stumpf — Fri, 17 May 2013 16:59:07 +0000

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:

Smart Property Changed Notification

Whenever a property changes in a property dependency network, the PDFx can optionally first analyze all the property dependencies and then fire the INotifyPropertyChanged.PropertyChanged event only once for every directly or indirectly dependent property. This analysis saves tremendous amounts of precious CPU time since every PropertyChanged event causes your UI layer to access and thereby reevaluate the bound properties.

Usage

By default, the smart property changed notification is turned on.
If you have a reason to switch this behavior off, you can set the Bindable class’s UseSmartPropertyChangedNotificationByDefault Property to false.

Performance Demonstration

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

Let us look at the following object graph:

Green circles stand for Input Properties while purple circles indicate calculated properties. The arrows show the underlying math operations as well as the property dependencies.

The number next to the lightning icon indicates how often the INotifyPropertyChanged.PropertyChanged event has fired since the D1 Property has changed the last time.

A change of D1 results in the following:

As the picture indicates, INotifyPropertyChanged.PropertyChanged is fired only once for every single property for maximum performance.

When the Smart Property Change Notification is switched off, a change of D1 results in the following:

In this scenario, the PDFx does not analyze the Property Dependency Network before INotifyPropertyChanged.PropertyChanged events are fired but rather blindly performs a depth-search traversal down the dependency tree along all directly and indirectly dependent properties and fires INotifyPropertyChanged.PropertyChanged for every single property it finds. As shown above, this behavior results in 10 PropertyChanged Notifications for the root node, A1.

To be more specific, the PDFx traverses the tree in the following manner, if smart property change notification is switched off:

D1 -> C1 -> B1 -> A1
	 -> B2 -> A1
   -> C2 -> B2 -> A1
         -> B3 -> A1
   -> C3 -> B3 -> A1
         -> B4 -> A1
   -> C4 -> B4 -> A1
         -> B5 -> A1
   -> C5 -> B5 -> A1
         -> B6 -> A1

It becomes obvious that the PropertyChanged event is inefficiently raised 10 times for Property A1 although once would be completely sufficient. Consequently, it is advisable to always take advantage of the smart property notification.

PDFx – Property Dependency Framework – Part X, Caching

Kevin Stumpf — Fri, 17 May 2013 16:52:16 +0000

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:

Caching

The PDFx allows you to cache Property evaluations and thereby avoid unnecessary executions of the very same evaluation business logic while the underlying data stayed the same.
When the INotifyPropertyChanged.PropertyChanged event is fired for a property, its cached value gets invalidated because the PDFx assumes that the underlying data has changed.
If a cached property depends on other properties, the cached value consequently gets invalidated as soon as any of its direct or indirect source properties change.
This feature helps to save precious CPU time when property evaluations become costly.

The following example demonstrates the usage:

class CacheDemonstration : BindableExt
{
	private AnyType _property1;
	public AnyType Property1
	{
		get { return _property1; }
		set { _property1 = value; NotifyPropertyChanged(() => Property1); }
	}

	private AnyType _property2;
	public AnyType Property2
	{
		get { return _property2; }
		set { _property2 = value; NotifyPropertyChanged(() => Property2); }
	}

	public AnyOtherType DependentProperty
	{
		get
		{
			Property(() => DependentProperty)
				.Depends(p => p.On(() => Property1)
				               .AndOn(() => Property2));

			return CachedValue(() => DependentProperty,
			                   () =>
				               {
					               return Property1 + Property2;
				               });
		}
	}
}

To use the caching feature, simply wrap the Property’s evaluation logic in a call to the Method CachedValue. The first parameter points to the current property while the second parameter points to a delegate that evaluates the property’s business logic.

When DependentProperty is evaluated for the first time, it calculates the property’s value and caches it. Whenever the property is evaluated the next time, it returns the cached value without re-evaluating Property1 or Property2.
As soon as Property1 or Property2 change, however, DependentProperty’s cached value is invalidated and upon its next access re-evaluated and cached again.

Simple Example

Let’s consider the following object graph:

Green circles stand for Input Properties while purple circles indicate calculated properties. The arrows show the underlying math operations as well as the property dependencies.

Such a graph can easily be implemented using the PDFx:

class SimpleCachingExample : BindableExt
{
	public int A1
	{
		get
		{
			Property(() => A1)
				.Depends(p => p.On(() => B1));

			return B1;
		}
	}

	public int A2
	{
		get
		{
			Property(() => A2)
				.Depends(p => p.On(() => B1));

			return 3 * B1;
		}
	}

	public int B1
	{
		get
		{
			Property(() => B1)
				.Depends(p => p.On(() => C1)
							   .AndOn(() => C2));

			return CachedValue(() => B1, () =>
				                             {
					                             return C1 + C2;
				                             });
			//Note the usage of CachedValue
		}
	}

	private int _c1;
	public int C1
	{
		get { return _c1; }
		set { _c1 = value; NotifyPropertyChanged(() => C1); }
	}

	private int _c2;
	public int C2
	{
		get { return _c2; }
		set { _c2 = value; NotifyPropertyChanged(() => C2); }
	}
}

A subsequent evaluation of A1 and A2 will result in only one evaluation of B1‘s business logic. Any future request of B1 will return the cached value. As soon as C1 or C2 change, B1‘s cached value gets invalidated and reevaluated when its accessed the next time.

Performance Demonstration

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

Let’s consider the following object graph:

The indicator next to the calculator icon shows the number of Property Evaluations since any Input Property (E1 through E6) has last changed.

A change of E1 with caching enabled results in the following:

Only D1, C1, B1 and A1 get re-evaluated. This makes perfect sense, since those are the only properties that are directly or indirectly dependent on E1.

Without caching, however, a change of E2 results in the following:

The PDFx notices that D1, C1, B1 and A1 all need to get reevaluated and fires INotifyPropertyChanged.PropertyChanged for all of them. The UI layer consequently accesses all of them and causes a reevaluation.
A reevaluation of for example A1 will now access – amongst others -B1. Consequently, B1 is unnecessarily evaluated again (first time it was evaluated by the UI layer). And the game goes on for all the other properties and has a larger performance impact the more intricate your object graph becomes.

The ViewModel for the example above can be implemented as follows:

class CachingDemonstrationVM : BindableExt
{
	public int A1
	{
		get
		{
			Property(() => A1)
				.Depends(p => p.On(() => B2)
							   .AndOn(() => B1));

			return CachedValue(() => A1, () => B1 + B2);
		}
	}

	public int B1
	{
		get
		{
			Property(() => B1)
				.Depends(p => p.On(() => C1)
							   .AndOn(() => C2));

			return CachedValue(() => B1, () => 2 * C1 - C2);
		}
	}

	public int B2
	{
		get
		{
			Property(() => B2)
				.Depends(p => p.On(() => C2)
							   .AndOn(() => C3));

			return CachedValue(() => B2, () => -C2 + C3);
		}
	}

	public int C1
	{
		get
		{
			Property(() => C1)
				.Depends(p => p.On(() => D1)
							   .AndOn(() => D2));

			return CachedValue(() => C1, () => D1 + D2);
		}
	}

	public int C2
	{
		get
		{
			Property(() => C2)
				.Depends(p => p.On(() => D3)
							   .AndOn(() => D4));

			return CachedValue(() => C2, () => 3 * D3 + 3 * D4);
		}
	}

	public int C3
	{
		get
		{
			Property(() => C3)
				.Depends(p => p.On(() => D5)
							   .AndOn(() => D6));

			return CachedValue(() => C3, () => D5 + D6);
		}
	}

	public int D1
	{
		get
		{
			Property(() => D1)
				.Depends(p => p.On(() => E1));

			return CachedValue(() => D1, () => E1);
		}
	}

	public int D2
	{
		get
		{
			Property(() => D2)
				.Depends(p => p.On(() => E2));

			return CachedValue(() => D2, () => E2);
		}
	}

	public int D3
	{
		get
		{
			Property(() => D3)
				.Depends(p => p.On(() => E3));

			return CachedValue(() => D3, () => E3);
		}
	}

	public int D4
	{
		get
		{
			Property(() => D4)
				.Depends(p => p.On(() => E4));

			return CachedValue(() => D4, () => E4);
		}
	}

	public int D5
	{
		get
		{
			Property(() => D5)
				.Depends(p => p.On(() => E5));

			return CachedValue(() => D5, () => E5);
		}
	}

	public int D6
	{
		get
		{
			Property(() => D6)
				.Depends(p => p.On(() => E6));

			return CachedValue(() => D6, () => E6);
		}
	}

	private int _e1;
	public int E1
	{
		get { return _e1; }
		set
		{
			_e1 = value;
			NotifyPropertyChanged(() => E1);
		}
	}

	private int _e2;
	public int E2
	{
		get { return _e2; }
		set
		{
			_e2 = value;
			NotifyPropertyChanged(() => E2);
		}
	}

	private int _e3;
	public int E3
	{
		get { return _e3; }
		set
		{
			_e3 = value;
			NotifyPropertyChanged(() => E3);
		}
	}

	private int _e4;
	public int E4
	{
		get { return _e4; }
		set
		{
			_e4 = value;
			NotifyPropertyChanged(() => E4);
		}
	}

	private int _e5;
	public int E5
	{
		get { return _e5; }
		set
		{
			_e5 = value;
			NotifyPropertyChanged(() => E5);
		}
	}

	private int _e6;
	public int E6
	{
		get { return _e6; }
		set
		{
			_e6 = value;
			NotifyPropertyChanged(() => E6);
		}
	}
}