There are many advantages to using the .NET Framework add-in technology to factor application logic and UI, including security isolation, discovery, activation, communication, lifetime management, and versioning.
WPF builds on the .NET Framework add-in technology to enable visual add-ins ie add-ins that provide UI for host applications to display. All that you need to do is define the contract to specify what types of things the host wants the add-in's UI to do. The end result for the user is that they see both host and add-in UI intermingled without knowing about the complex machinery underneath to make it work.
And, to some degree, developers might approach the development of add-ins the same way. For example, when a WPF host application displays a UI provided by an add-in, developers might intuitively expect features like data binding, commanding etc to just work. Features like this, though, need a little extra work to, err, get working because features like these weren't originally designed to work across the isolation boundary between host and add which is the space between the host's application domain and the add-ins application domain. (This use of application domains enables security isolation.)
The attached sample demonstrates how to implement host/add-in applications to support data binding. Specifically, the sample shows a host application that manages a data object (Person) and provides it to UI add-ins that either re-visualize the data or allow editing of the data, or both. Here's how the application looks at run time.
To understand the sample, you'll need to be familiar with .NET Framework and WPF add-in support. This SDK document provides a good starting point.
You'll need to play with the sample to see how it really works but the 10000' view is:
- There is one contract for the Add-In
- There is one contract for the Person data object
- The host instantiates the Person data object and binds some UI to it.
- The host activates and displays a UI provided by the add-in, to which the host passes the Person object. The add-in UI also binds to the Person object.
- When the host UI that is bound to the data object is updated, the changes are communicated to the add-in UIs that are also bound to the data object.
- When the editable add-in UI that is bound to the Person data object is updated, the changes are communicated back to the host.
To the host and add-in UIs, all they see is a Person data object that implements INotifyPropertyChanged which is the data binding interface that essentially ensures bound UI are updated when the data objects they are bound to are updated. The add-in pipeline to make this work is a little more involved, technically, but is the same as using INotifyPropertyChanged, in concept.
You'll find the best way to grok the sample is to download it and see it running.