The Model-View-ViewModel (M-V-VM) pattern is a refinement of the Presentation Model pattern, specific to WPF and Silverlight development. The basic idea is to develop user interfaces by separating the code into three functional components.
The Model contains the data and domain logic of the application, with no knowledge of how the data will be shown (or even if it will be shown) to the user. This is the heart of the application. It's not uncommon for the
Model to implement INotifyPropertyChanged or INotifyCollectionChanged, but it's not necessary.
The View is responsible for displaying information to the user, and for providing a means for input. In M-V-VM, the view displays information by data binding to the
ViewModel, while input is handled by raising events, executing Commands and, again, data binding.
Testing the View is generally very difficult. UI automation is about the only tool available to you, but UI automation is complex and fragile. Issues such as discovering controls, providing complex user interaction scenarios and timing all make writing
UI automation code difficult. The general fluidity of the UI during development, when controls will be moved, swapped out for other controls and other typical design alterations, will often break UI automation code. Various aspects of the application can make
timing in the UI automation code fail. Finally, because UI automation code generally acts like a user, driving the mouse and keyboard, these tests require exclusive access to the desktop. They can't be run "headless" (i.e. in an account that
doesn't have access to the desktop) and can fail if anyone or any other process interacts with the mouse, keyboard or other input devices while the tests are running.
Because of these difficulties, the View is created with as little logic as possible.
The ViewModel models the state and user interaction logic for the View. The
View uses data binding to keep it's state in sync with the ViewModel state, and defers all event and command handling logic to methods on the
There are several issues that must be addressed when following the M-V-VM pattern in WPF. First, despite the power and flexibility of the data binding system, not all state can be easily bound. For instance, out of the box today, it's not easy to bind the
selected items in a multi-select ListBox to a collection in the ViewModel. Second, it's not uncommon for event and command handling logic to include tasks that would tie the
ViewModel to UI code. For instance, something as simple as displaying a
MessageBox would make the ViewModel difficult to test, yet that's a very common scenario. It's these issues that
Onyx tries to address.