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
Introduction
The Property Dependency Framework (PDFx) is a lightweight library that allows you to capture the inherent relationship among the properties of your classes in a declarative manner. It is common in applications to have properties whose values depend upon the values of other properties. These properties need to be reevaluated when a change occurs in the properties on which they depend. For example, if “A” depends on “B” and “C”, we need to reevaluate the value of A whenever either B or C changes. Furthermore, B and C may not even be direct properties of the same class as that in which A exists. Instead, they may be properties of another class, or even properties of the items within a collection.
In large applications, complex chains of such dependencies can exist. Although C# gives us the INotifyPropertyChanged construct to send out a change notification (typically to UI elements), no framework to our knowledge has allowed the network of dependencies to be specified in a straightforward manner, with the proper change notifications issued automatically. The PDFx framework allows the dependencies of properties to be specified declaratively, building from them an internal network of dependencies for you. Changes to any property in the network are then propagated automatically and efficiently.
The PDFx framework establishes a simple pattern for capturing the relationships of data in applications, and removes tremendous amounts of “plumbing”. It also helps clarify and enhance the role of the View Model within MVVM, reducing the scattering of business logic throughout value converters. Once you’ve made use of PDFx, you will likely wonder how the gap it fills has gone unaddressed for so long.
Example
Since pictures tell better stories than words, I would like to demonstrate the benefits of this workhorse with a small example:
The depicted algebra hierarchy represents a C# class. 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.
As the developer of such a scenario, you’re responsible to ensure that all directly and indirectly dependent properties get reevaluated when an input property changes. Furthermore, for efficiency reasons, you also want to ensure that all unrelated properties do not get reevaluated.
If, for example, Property D1 changes, it is necessary to reevaluate C1, B1 and A1.
However, a change of D3 requires a reevaluation of only C2, B1, B2 and A1.
Using the PDFx, you don’t have to manually hardcode those relationships anymore but can rather rely on the library taking care of this job for you.
All you have to do is register the relationships in human readable code within the implementation of a property:
//.... public int A1 { get { Property(() => A1) .Depends(p => p.On(() => B1) .AndOn(() => B2)); return B1 + B2; } } public int B1 { get { Property(() => B1) .Depends(p => p.On(() => C1) .AndOn(() => C2)); return 2*C1 - C2; } } public int B2 { get { Property(() => B2) .Depends(p => p.On(() => C2) .AndOn(() => C3)); return -C2 + C3; } } public int C1 { get { Property(() => C1) .Depends(p => p.On(() => D1) .AndOn(() => D2)); return D1 + D2; } } public int C2 { get { Property(() => C2) .Depends(p => p.On(() => D3)); return 3*D3; } } public int C3 { get { Property(() => C3) .Depends(p => p.On(() => D4) .AndOn(() => D5)); return D4 + D5; } } //....
Advanced Features
- Dependencies on properties of external objects
- Dependencies on ObservableCollections
- Property Value Caching
- (Deferred) Callbacks for Property Changes
Main Benefits
- The dependency registration resides within the Property Getter implementation. This way you’re likely to notice immediately that an update of the registration is necessary when you change a property’s implementation.
- The PDFx fires the PropertyChanged event only for Properties that are directly or indirectly dependent on the changed source property, thereby guaranteeing a high level of efficiency.
- Properties whose data relies completely on the value of other properties do not need to encapsulate backing fields. They can be implemented solely in the Property Getter, thereby ensuring full integrity.
Pingback: PDFx – Property Dependency Framework – Part II, Library Versions | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part III, Getting started | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part IV, Using PDFx with an existing 3rd party framework | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part V, Simple Property Dependencies | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part VI, External Property Dependencies | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part VII, Dynamic External Property Dependencies | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part VIII, Collection Dependencies | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part IX, Dynamic Collection Dependencies | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part X, Caching | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part XI, Smart Property Changed Notification | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part XII, Callbacks | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part XIII, Sanity Checks | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part XIV, Data Delegation | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part XV, Two Way Converters | //InterKnowlogy/ Blogs
Pingback: PDFx – Property Dependency Framework – Part XVI, One Way Converters | //InterKnowlogy/ Blogs
Pingback: //InterKnowlogy/ Blogs
Pingback: MVVM pain points: Chained/Dependent/Calculated Properties | PhilChuang.com