Data-binding is the heart of what drives the XAML-based layout system in Silverlight. It allows a clean separation between the visual appearance/user interface and the rest of the application. Data-binding comes at a price, however, because it is not part of the normal logic flow of the application and has been notoriously difficult to debug. Data-binding changes dramatically in Silverlight 5.
The availability of ancestor relative source binding allows inner, nested elements to reference elements higher up the visual tree. For example, a row in a grid can provide a command that binds to a higher level container instead of the specific data for that row. Implicit data templates allow the developer and/or designer to describe views based on the type of data being displayed so that the rendering engine will automatically select the correct view when data is bound.
Style data-binding provides unprecedented runtime control over themes. Styles can now have bindings specified, and developers or designers may supply classes that manage theme elements such as brushes and gradients. Changing the values on the theme elements will automatically update all elements that implement the particular style.
The most awaited feature is data-binding debugging (see Figure 3). Some people mistakenly refer to it as XAML debugging, but there is not access to debug the entire XAML parsing process. Instead, breakpoints can be set on data-binding statements. These provide access to a set of local variables to diagnose the target of the data-binding and the underlying values, and help the developer troubleshoot what went wrong when a particular data-binding doesn’t work as expected.
Figure 3 Data-binding debugging