- Represent the state and behavior of the presentation independently of the GUI controls used in the interface
- Is a specialization of the more general Presentation Model pattern, tailor made for WPF and Silverlight.
- separation of functional development provided by MVC as well as leveraging the advantages of XAML and binding.
- Model - an object model that represents the real state content.
- View - refers to all elements displayed by the GUI such as buttons, windows, graphics, and other controls.
- ViewModel - abstraction of the View that also serves in data binding between the View and the Model. Conceptual state of the data as opposed to the real state of the data.
- “A screen and components with all application specific behavior extracted into a controller so that the widgets have their state controlled entirely by controller.”
- solves the problem of testability.
- handles this by reducing the behaviour of the UI components to the absolute minimum by using a controller that not just handles responses to user events, but also does all the updating of the view.
- “Factor the UI into a view and controller where the view handles simple mapping to the underlying model and the controller handles input response and complex view logic.”
- 2 responsibilities
- input response: the user gestures are handled initially by the screen widgets, however all they do in response is to hand these events off to the presenter, which handles all further logic.
- partial view/model synchronization: the view uses some form of Data Binding to populate much of the information for its fields.
This interface exposes a single event that screen widgets subscribe to. The event should be raised when any properties on the subject have changed, this signals the UI to synchronize with the current state of the ViewModel. There are a few things that I don’t like about common usage of this interface and that is hard coded string sprinkled across your source code. this is not refactoring friendly and does not provide you with any sort of compile time errors when an incorrect property name is provided. This is an implementation of the Observer design pattern.
“The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.” - Head First Design Patterns
Example 1. Using Inheritance
Example 2. Using Composition
When binding a screen widget to a collection you can create a collection that implements this interface to signal the widget when items are added or removed. When you add a new item to the collection raise the CollectionChanged event to signal the UI to rebind to the collection.
The built in [ObservableCollection
This interface defines an action that screen widgets can invoke when they are activated. The simplest example is a Button. When a button is clicked it will execute the command that it is bound to. If the command cannot be executed then the button will become disabled.
This is an implementation of the Command Pattern and the Specification Pattern.
“The Command Pattern encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.” - Head First Design Patterns
“In computer programming, the specification pattern is a particular software design pattern, whereby business logic can be recombined by chaining the business logic together using boolean logic.”
This synchronization is done via this interface. When a condition in the application changes the ability for a command to be executed, the command must raise the CanExecuteChanged event to signal the UI to check if the command can be executed.
This interface is used to synchronize errors in the view model on to the screen. When your ViewModel implements this interface, the screen will send it the name of each property that it is bound to, in order to tell if there is a validation error with it. If an error is returned the default red line around the control is displayed.
- powerful databinding.
- you can bind to:
- public properties
- requires both a target and a source
- a target can be any property that is derived from DependencyProperty eg. TextBox
- a source can be and public property, controls, objects, xaml elements, ado.net datasets, xml fragments.
- Josh Smith has an excellent article data binding in wpf on codeproject.
The class System.Windows.FrameworkElement has a property on it named DataContext of type object. This is a very special property that every screen widget inherits. When the DataContext is set to an object, every control within that control has its DataContext set to that same object.
In the following example, when the DataContext is set on the DockPanel, the Label and Button have the same DataContext. That means that the Label and the Button can bind to properties on the same object.
Value converters are used to convert objects from one type to another. When used in the UI, the value converter is used to convert back and forth from the View to the ViewModel.