Data binding creates a live connection between your UI elements and underlying data sources. Instead of manually updating controls when data changes, WPF's binding engine handles synchronization automatically. You declare bindings in XAML using the Binding markup extension, specifying a path to your data and how updates should flow between source and target.
This declarative approach separates presentation from logic, making your code cleaner and more maintainable. A binding source can be any CLR object, collection, or XML document. The target must be a dependency property on a UI control, typically properties like Text, ItemsSource, Background, or Visibility that drive visual behavior.
Any dependency property can serve as a binding target. Common scenarios include binding TextBox.Text to a string property, ListBox.ItemsSource to a collection, or Button.Background to a color value. The dependency property system notifies WPF when values change, triggering automatic UI updates without manual intervention.
You can bind multiple properties on the same control to different sources. For instance, a data grid might bind its ItemsSource to a product list while binding IsEnabled to a view model's CanEdit property. This flexibility lets you create responsive UIs that react to complex business rules without tight coupling between components.
A binding source provides the data your UI displays. For object data, set the Path property to reference a property on your source object. When binding to collections, Path points to the collection property while the control's item template defines how individual items render. XML sources use XPath queries to select nodes, and you can combine Path with XPath to bind to properties on the selected XML node.
You set the source explicitly using the Source property, or WPF searches up the visual tree for a DataContext. The DataContext approach promotes reusability, child controls automatically inherit their parent's DataContext, reducing repetitive binding declarations. This inheritance makes it easy to bind an entire form to a single view model instance.
public class ProductViewModel : INotifyPropertyChanged
{
private ObservableCollection _products;
private Product _selectedProduct;
public ObservableCollection Products
{
get => _products;
set { _products = value; OnPropertyChanged(); }
}
public Product SelectedProduct
{
get => _selectedProduct;
set { _selectedProduct = value; OnPropertyChanged(); }
}
public event PropertyChangedEventHandler PropertyChanged;
protected void OnPropertyChanged([CallerMemberName] string name = null)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
}
} The Mode property controls data flow direction. OneWay flows from source to target only and use this for read-only displays like labels or status indicators. TwoWay enables bidirectional updates, perfect for editable forms where user input writes back to the source. OneTime evaluates the binding once at initialization, useful for static configuration values. OneWayToSource reverses the flow, pushing target changes to the source without reading from it.
UpdateSourceTrigger determines when TwoWay bindings push changes back to the source. LostFocus (the default for TextBox) updates when the control loses focus, batching multiple edits into one source update. PropertyChanged updates immediately on every keystroke or value change, enabling real-time validation but increasing update frequency. Explicit requires manual UpdateSource calls from code, giving you precise control over when data commits.
private void ApplyPrice_Click(object sender, RoutedEventArgs e)
{
// Force explicit binding to update source
BindingExpression binding = PriceBox.GetBindingExpression(TextBox.TextProperty);
binding?.UpdateSource();
// Validate and save
if (IsValid(PriceBox))
{
((ProductViewModel)DataContext).SaveProduct();
}
}A binding target must be a dependency property on a UI element-common examples include TextBox.Text, ListBox.ItemsSource, or Button.Background. Sources can be any CLR object, ObservableCollection, or XML document. For sources to notify the UI of changes, objects should implement INotifyPropertyChanged and collections should use ObservableCollection<T>.
Use OneWay for read-only displays like labels and status indicators where data flows from source to UI only. Choose TwoWay for editable forms where user input needs to update the underlying data model. OneTime works for static configuration values that never change after initialization. OneWayToSource is rare but useful when a UI control like a Slider updates a property without reading from it.
The default LostFocus works well for most forms, updating the source when users tab away or click elsewhere. Switch to PropertyChanged for real-time validation scenarios where you need instant feedback on every keystroke. Use Explicit when you want complete control...for example, validating complex business rules before committing changes with a Save button, or batching multiple field updates into a single transaction.