Data Binding
So far in the tutorial we've examined a large number of the controls provided by Windows Presentation Foundation (WPF). We've configured them, primarily using XAML, and responded to their events with C# code. Generally, the properties that we've manipulated provided simple, discrete values or linked to basic collections.
The next group of controls that we will consider are the data display controls. These show large amounts of data in lists, grids or tree structures. To achieve the best results with these controls requires the use of data binding. Before demonstrating these controls it's important to understand the basic concepts of data binding and how it is implemented. We'll look at these topics in this and the next few articles, before examining the data display controls.
What is Data Binding?
When you are developing software that presents data for viewing or editing, that information needs to be copied into the properties of the user interface controls on loading and must be copied back into data objects when altered. This can lead to a lot of boilerplate code that simply retrieves or updates property values, formats values for display and validates the information provided by the user. This boilerplate code is often repetitive and tedious to produce.
Data binding helps to simplify the linking of controls to data. You can create bindings for user interface controls declaratively in the XAML, or programmatically in code. Bindings link two pieces of information and allow them to automatically update each other. For example, you might create a C# class that represents all of the information required to complete a form. A WPF window could be bound to an object of this type, using data binding expressions declared in the XAML. The properties of the object might then be displayed automatically and any changes that the user makes could update the data in the object.
One of the benefits of data binding is the increased separation of concerns; the user interface and the business logic are no longer directly linked. As long as the interface provided by underlying data objects is agreed, a designer can create the user interface without writing any C# code. At the same time, a programmer can develop the business logic without using XAML. Later, the two parts of the software can be brought together.
Another benefit of the separation of the user interface and the business logic through data binding is increased testability. It is a simple matter to unit test the business logic when no user interface is connected to it. All of the user interactions can easily be simulated in unit tests by simply changing properties. This is often achieved using a design pattern known as Model View ViewModel, or MVVM.
Source and Target
When you create bindings, you specify a source and a destination. The source is the underlying data. This might be a basic object, a collection, another user interface control, some XML or some other data. In addition, you provide a path to the information to bind. For example, you might wish to bind a TextBox to a string held in a data object's property. In this case, the binding source is the data object and the path identifies the property.
The target for a data binding must be a dependency property. This restriction is usually not a problem, as most of the properties provided by user interface controls are dependency properties. In the aforementioned example, the binding target would be the Text property of the TextBox.
You can use the same source and path for multiple data binding targets. This is useful for rich user feedback. For example, you might show the progress of a long-running task with a ProgressBar that is linked to a progress value property. You may decide to simultaneously display the same value as a percentage within a TextBlock.
Binding Direction and Triggers
Defining a source and a target for a binding might suggest that information is transferred in one direction only. This is not the case. There are four options available to determine how information propagates between the source and target. You can create a bi-directional binding that copies changes in either the source or the target to its counterpart. You can create a one-direction binding in either direction and you can create a one-time binding, which sets the value in the target on loading but no further changes are transmitted.
Updates from the source to the destination are triggered by events. WPF automatically attaches to key events to determine when bound values change. The new data is then copied into the target, according to the rules set in the binding expression. Not all binding sources support these events. For example, a simple class with automatically implemented properties will not send updates to the user interface. Such classes must implement known interfaces, such as INotifyPropertyChanged, to operate correctly as binding sources. We'll see how this is achieved later in the tutorial.
Data updates from the binding target to the source are controlled in the binding expression. You can elect to update automatically with every user interaction, or only change values when a control loses focus. The choice depends upon the use case. For example, you may want a CheckBox or RadioButton click to immediately update the source data. For a TextBox, this may cause problems, as every key pressed will trigger an update. If neither solution is appropriate for your scenario, you can elect to trigger updates manually.
19 August 2014