I recently created a design pattern, called “Virtual Branches”, which allows elements that are not in the logical tree to bind against the DataContext in the logical tree. Shortly after I posted the article about virtual branches, Douglas Stockwell posted an interesting response which expressed doubt regarding the usefulness of the pattern.
Stockwell demonstrated how the problem shown in the article could be solved without using a virtual branch. His solution was to hoist the demo’s IsMultipleOfValidationRule into the Window’s Resources and bind the Slider’s Value directly to a Divisor property on the rule. Then he referenced the ValidationRule as a StaticResource from the TextBox.Text’s Binding. This works, but I feel strongly against this design (as does Stockwell).
Binding a Slider to a ValidationRule used by a Binding in a TextBox introduces a very artificial coupling. The only relationship which the Slider and ValidationRule share is that they both need to access the same property on the data context object. Specifically, they both need access to the Divisor property on a DivisionNumbers instance. That’s all they have in common. There is no reason why they should be aware of each other.
Using a virtual branch in this situation removes the unnecessary coupling. The ValidationRule is not directly dependent upon the Slider to ensure that it has the correct Divisor value. Later if the Slider is removed, or the ValidationRule is created programmatically, or alternate ways for the user to modify the Divisor are introduced, there will be no knots to untie.
Virtual branches provide a layer of indirection which allows you to bind against properties on the domain object, not against properties on other objects in the element tree. In general, this is a better design tactic because it promotes ignorance (i.e. elements don’t know about each other). Ignorance can be bliss.