XAML 101: Getting Started with Data Binding


Source code for this post on GitHub: https://github.com/billreiss/xamlnative/tree/master/Xaml101/015_DataBinding

Data binding is a huge topic in XAML, it’s pervasive and whether you are following the Model View ViewModel (MVVM) design pattern that’s very popular in XAML or  if you just want to populate a list of elements, you’ll probably need to use data binding in some form in your app. We will cover some now, and then there will probably be more topics as we progress.

Data binding has been around a long time. You could do it in Windows Forms apps. PowerShell and Delphi were built around it. I feel that with XAML they finally got it right, and it has made it to the point where if you’re not using it to build your app, you may be doing it wrong.

Data binding gives you a bridge between the data and the layout, and reduces the code you need to write to wire these two parts together. In earlier XAML based frameworks (WPF, Silverlight, WinRT for Windows 8) data binding was very dynamic and a lot was done at run time using reflection to make it work. Reflection is slow and memory intensive. When the Windows Shell team and the Office team started using XAML to develop Windows 10 apps and shell components, they ran into these performance and resource issues and came back to the Windows 10 Universal Windows Platform (UWP) team and asked for guidance. These teams are so focused on performance and will reject a technology if it doesn’t fit their needs. At first the UWP team considered guiding them to not use data binding and just wire up everything in code, which is what was typical in WinForms apps. Then they came up with a better way. More about it here. There is a new data binding system in Windows 10 UWP and it removes most of the old concerns about performance issues in traditional data binding in XAML. We won’t cover the old method of data binding, at least not yet, because I feel it’s best to lead in the recommended direction for best practices.

So what’s different about the new way? The heavy lifting is done at compile time. Code is generated to improve performance. No reflection is used. Binding errors are found at compile time. You can put breakpoints in the generated code. The defaults are set to maximize performance. Unless it doesn’t do what you need in some specific situation, I recommend using the new way. The new way is referred to as compiled bindings, or xBind.

Data bindings in general or xBind in particular are XAML markup extensions. We have seen some of these already, specifically ThemeResource and StaticResource. It’s a bit of a testament to XAML that Microsoft was able to swap out the data binding strategy.

NOTE: Compiled bindings are only currently available in Windows 10 UWP apps. I would love to see them in WPF too, if you agree go vote for it at http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/7810488-implement-x-bind-for-wpf. Microsoft really pays attention to this and you can make a difference.

In over 15 posts so far in the  XAML 101 series, I don’t think we have actually left XAML and written a line of C# code. There is only so much you can do in straight XAML and at some point the data needs to come from somewhere. Later we’ll dig into some design patterns and some suggestions on how to organize your code but data binding is useful without all of that.

Let’s look at a couple of very simple data binding examples, and then we can go from there in future posts. Consider these changes to the MainPage.xaml.cs file:

public sealed partial class MainPage : Page
    string FieldBindingText = "Here is a Field Binding";
    string PropertyBindingText
        get; set;

    public MainPage()
        this.PropertyBindingText = "This is a Property Binding";

We have two strings, one is a field and one is a property. Now in the MainPage.xaml we can do this:

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <TextBlock Text="{x:Bind FieldBindingText}"/>
        <TextBlock Text="{x:Bind PropertyBindingText}"/>

Notice the Text properties use the x:Bind markup extension, and the names match the string field and property we created in the code behind file. The compile bindings markup extension automatically looks to the current class definition for matching elements. running the app looks like this:


Let’s then change the first TextBlock to look like this:

<TextBlock Text="{x:Bind aFieldBindingText}"/>

Since the name specified no longer can find a match, we get a compile time error:


That’s it for now, stay tuned.