XAML DataBinding Clarity

Question

Want to see if someone could help clear this up for me? Is there an advantage to DataBinding from the XAML Element to a value within the ViewModel(ex:1), or from the CodeBehind(ex:2) back to the Element like... HostName.Text?

<TextBlock Text="{Binding HostName}" /> --- (ex:1)
<TextBlock Name="HostName" /> --- (ex:2)

POGO

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.Text;
using System.Threading.Task;

namespace AppName.Models
{

public class Contact
{
    [Key]
    public int Id {get; set;}
    public string Team { get; set;}
    public string FirstName { get; set;}
    public string LastName { get; set;}
    public string Phone { get; set;}
    public string Email { get; set;}
    public string Role { get; set;}
    public string DisplayName => $"[LastName}, {FirstName}";
}
}

Answer 1

The simple answer is that it depends on your application and needs. When you're building a small application, using code behind or data binding to view models doesn't make much difference. It's easy to understand the flow and when to make updates. But as your app complexity goes up and your need to test your code, then you start to use patterns that makes your code more maintainable and testable. That's where the MVVM pattern came from.

Testing code in your code behind file is harder than just testing your business logic in your ViewModel class, and ensuring it works as expected.

Your example above is kind of simplistic because it's a TextBlock that only displays text and doesn't take input. A TextBox is a better example for binding since data can change in the view model or in the UI. Binding lets you back the displayed text with a property, so changes from any direction update the model property and UI automatically.

<TextBox x:Name="Entry" Text="{Binding SelectedValue , Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />

ViewModel:

public class CatalogViewModel : BindableBase
{
    private string selectedValue;
    public string SelectedValue
    {
        get { return selectedValue; }
        set { SetProperty<string>(ref selectedValue, value); }
    }
...
}

The alternative to that is a lot of code in the code-behind file to keep things in sync between the TextBox and data elements.

<TextBox x:Name="Entry2" TextChanged="Entry2_TextChanged" />

Code behind:

private string entryText;
public string EntryText
{
    get { return entryText; }
    set
    {
        if (value != entryText)
        {
            entryText = value;
            Entry2.Text = entryText;
        }
    }
}
private void Entry2_TextChanged(object sender, TextChangedEventArgs e)
{
    entryText = Entry2.Text;
}
private void Page_Loaded(object sender, RoutedEventArgs e)
{
    // initialize controls
    EntryText = "Default";
}

You've now coupled your business logic with the page layout and changes to either will cause a lot of changes. And testing the behavior of your code is harder to write and harder to mock.

And it just gets more complicated with multiple input controls and more complex controls, like ListViews and GridViews.

You should read up on MVVM if you're interested in the benefits of using view models and databinding to them: https://msdn.microsoft.com/en-us/magazine/dd419663.aspx.