Silverlight Data Binding

Analogy categoryAnalogies

The Binding Markup Extension

A Silverlight Binding connects a target dependency property (on a UI element) to a source, most commonly a property on a CLR object reachable through DataContext, using syntax like Text="{Binding Path=Name}". DataContext is inherited down the visual tree, so setting it once on a parent (typically in code-behind: this.DataContext = viewModel) lets every descendant element bind against the same object without repeating the source per control. Binding.Mode controls direction: OneTime reads the value once, OneWay pushes source-to-target updates only, and TwoWay synchronizes both directions, which is essential for editable input controls like TextBox.

🏏

Cricket analogy: DataContext being inherited down the visual tree is like a captain's tactical plan for the day being communicated once at the team huddle and then every fielder on the ground automatically knows the target field placement without the captain repeating it to each player individually.

INotifyPropertyChanged and Live Updates

For OneWay or TwoWay bindings to reflect changes after the initial render, the source object must implement INotifyPropertyChanged, raising a PropertyChanged event with the changed property's name whenever a bound property is set; Silverlight's binding engine subscribes to this event and refreshes the target automatically. ObservableCollection<T> plays the analogous role for collections bound to an ItemsControl: adding or removing items raises CollectionChanged, which the ItemsControl listens for to insert or remove the corresponding generated container without a full rebind, whereas a plain List<T> assigned to ItemsSource will not reflect subsequent Add/Remove calls in the UI at all.

🏏

Cricket analogy: INotifyPropertyChanged is like a scoreboard operator who immediately updates the display the instant a run is scored, rather than the crowd having to wait until the innings ends to see the new total, while a plain List<T> without notification is like a scoreboard that's frozen until manually refreshed at the next break.

Converters and Validation

An IValueConverter implements Convert (source-to-target) and ConvertBack (target-to-source) to transform data during binding, such as turning a boolean IsActive property into a Visibility value for a status indicator, or formatting a DateTime into a localized string; converters are referenced in XAML via Converter={StaticResource someConverter} and can accept a ConverterParameter for lightweight configuration. For input validation, implementing IDataErrorInfo or throwing an exception in a property setter (combined with ValidatesOnExceptions=True and NotifyOnValidationError=True on the Binding) lets Silverlight surface a red validation border and error tooltip automatically on the offending control.

🏏

Cricket analogy: A converter turning a boolean IsActive into Visibility is like a broadcast graphics system translating a raw "is the batsman out" flag into a visual DRS animation, transforming underlying data into a presentable form, while IDataErrorInfo flagging an invalid run total is like the third umpire flashing a red light when the recorded score doesn't add up.

csharp

public class Customer : INotifyPropertyChanged
{
    private string _name;
    public string Name
    {
        get { return _name; }
        set
        {
            if (_name != value)
            {
                _name = value;
                OnPropertyChanged("Name");
            }
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged(string propertyName)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

public ObservableCollection<Customer> Customers { get; } = new ObservableCollection<Customer>();

Binding a TextBlock's Visibility to a boolean value requires a converter because Visibility is an enum (Visible/Collapsed), not a bool — a common BooleanToVisibilityConverter handles this translation and is reused across most Silverlight projects.

Assigning a plain List<T> (instead of ObservableCollection<T>) to an ItemsControl's ItemsSource means later Add or Remove calls on that list will not update the UI at all, since List<T> raises no CollectionChanged notification — the ItemsControl only reflects the collection's state at the moment of binding.

Binding connects a target dependency property to a source property, typically resolved through DataContext.
DataContext is inherited down the visual tree, so setting it once lets many descendant bindings share the same source.
Binding.Mode (OneTime, OneWay, TwoWay) controls the direction and frequency of updates.
INotifyPropertyChanged with a PropertyChanged event is required for OneWay/TwoWay bindings to reflect later changes.
ObservableCollection<T> raises CollectionChanged so ItemsControl reflects Add/Remove without a full rebind; plain List<T> does not.
IValueConverter's Convert/ConvertBack transform data between source and target representations, optionally using ConverterParameter.
ValidatesOnExceptions and IDataErrorInfo let Silverlight surface automatic validation error UI on invalid input.