WPF binding is great, but directly binding the View to the Model has its limitations. As soon as the Model’s and the View’s structure diverge (which happens quite fast, I was surprised myself) the direct binding approach falls apart. The first example where I hit this was a tree of items which should be displayed and selected in a (decorated) list. Data binding just doesn’t cut it. The solution lies in creating a so called
ViewModel.
The ViewModel
The ViewModel acts as an
Adapter between the View and the Model. A very intelligent Adapter. It contains all logic, properties and events to allow a “trivial” View implementation. This provides for a clear
separation of concerns:
- the Model as data store
- the View as vehicle for actual user interaction, that is drawing pixels and receiving input events
- the ViewModel to transform the data into view-specific structures, translate manipulation of these structures back into the Model and hold view-specific state
Example
A simple example for a ViewModel (or
Presenter Model, as it called in the
Composite Application Guidance for WPF) is the
CollectionView used as Adapter between the ListBox and a collection.
You can think of a collection view as a layer on top of a binding source collection that allows you to navigate and display the collection based on sort, filter, and group queries, all without having to manipulate the underlying source collection itself. If the source collection implements the INotifyCollectionChanged interface, the changes that raise the CollectionChanged event are propagated to the views.
Benefits
One of the nice effects of a ViewModel is the ability to share such a model, giving instant synchronisation between multiple Views. This works because the individual Views do not have any state, but are completely dependent on the ViewModel.
Another subtle but nice point is the massive reduction in imposed structure on the View. Only a single, light-weight injection interface is needed to give the View access to the ViewModel. This allows more flexibility in evolving the ViewModel, since only breaking changes affect all Views. On the other hand, Views can incrementally support more and more features of a given ViewModel without having to pay big up-front costs in implementing/stubbing a huge interface. In the same vein, the ViewModel has no dependency of the View in any kind, which makes the ViewModel the ultimate
lookless control.
Automated testing became a big topic over the last years and the ViewModel follows the trend by being very easy to test. To test a presenter/controller in a MVP or MVC architecture, both the View and the Model have to be replaced for a test. Since a View of a ViewModel shouldn’t contain any “real” code, testing can concentrate on the functionality of the ViewModel and only mock up the Model, something which is needed for most tests of components using the Model anyways.
Last (but perhaps not least) is a purely aesthetic point: All dependencies in a ViewModel architecture point in the same direction. The Model works with a data source, the Business Logic works with the Model, the ViewModel works with the Business Logic and the Model, and the View only works with the ViewModel. This enables the uniform re-use of the same mechanisms and patterns — Validation, Transactions, Change Notification, etc — over the various levels of the application.
Conclusion
ViewModels represent the current top of the evolution in
lookless controls. By combining data binding and the programmatic power of a Presenter/Controller component into a single concept without dependencies on a specific View technology, they provide a high degree of flexibility in representing the internal state of an application without getting bogged down in the intricate details of designing a great user experience.
I’m already thrilled how this will work out in more complex scenarios. And what’ll come next
