The Mechanics of TwoWay Binding
TwoWay binding establishes a bidirectional pipe between a UI control's property and a source property: the source-to-target direction works exactly like OneWay binding, listening for INotifyPropertyChanged and pushing new values into the control, while the target-to-source direction listens for the control's own change events (a TextBox's TextChanged, a CheckBox's Checked/Unchecked) and writes the new value into the ViewModel property's setter. Many editable controls default to TwoWay mode automatically — TextBox.Text, CheckBox.IsChecked, and Slider.Value all default to TwoWay in WPF — so developers frequently get two-way behavior without explicitly specifying Mode=TwoWay, which is convenient but can obscure what's actually happening when debugging.
Cricket analogy: TwoWay binding is like a captain and coach relaying strategy through an earpiece during a match — the coach's instructions flow down to the captain, and the captain's on-field read of the pitch flows back up.
UpdateSourceTrigger and Timing
UpdateSourceTrigger controls exactly when the target-to-source push happens. The default for most properties is PropertyChanged, meaning the source updates immediately as the control's value changes, but TextBox.Text specifically defaults to LostFocus for historical reasons, meaning the ViewModel only sees the new text once the user tabs or clicks away from the field. Explicitly setting UpdateSourceTrigger=PropertyChanged on a TextBox makes every keystroke propagate immediately, which is necessary for live search-as-you-type filtering or live validation feedback, but it also means the setter runs far more often, so expensive validation logic in that setter can introduce noticeable input lag if not optimized.
Cricket analogy: LostFocus-style updating is like a scorer only officially logging a batsman's total once the over ends, rather than updating the board after every single ball — accurate eventually, but not instant.
// ViewModel property with validation in the setter
private string _email;
public string Email
{
get => _email;
set
{
if (_email == value) return;
_email = value;
OnPropertyChanged(nameof(Email));
ValidateEmail(); // runs on every keystroke if UpdateSourceTrigger=PropertyChanged
}
}Validation Feedback Loops
Because TwoWay binding round-trips data, it's possible to create a feedback loop if the setter mutates the incoming value and the property fires a change notification that then re-writes the control, which can in some frameworks re-trigger the target-to-source push again. A common defensive pattern is to compare the incoming value against the current backing field before assigning and notifying — as shown in the code example above with the if (_email == value) return; guard — which stops redundant notification cycles. Additionally, when validation fails, ViewModels commonly implement IDataErrorInfo or INotifyDataErrorInfo so the binding engine can display a red border or error tooltip on the control without the setter needing to throw an exception, which would otherwise crash or silently drop the binding.
Cricket analogy: A guard clause against redundant updates is like an umpire not re-signaling a boundary that was already signaled — once the four is confirmed, repeating the identical signal on every replay would just be noise.
IDataErrorInfo and INotifyDataErrorInfo let a ViewModel report validation errors per-property so the binding engine can render error adorners (like a red border) without throwing exceptions from a property setter, which keeps the binding pipeline intact even when input is invalid.
Setting UpdateSourceTrigger=PropertyChanged on every TextBox by default can cause performance issues if setters perform expensive work (network calls, heavy validation, recalculating large collections) on every keystroke. Reserve PropertyChanged for fields that genuinely need live feedback and leave the rest on LostFocus.
- TwoWay binding combines OneWay's source-to-target push with a reverse target-to-source push triggered by the control's own change events.
- Many editable controls (TextBox.Text, CheckBox.IsChecked, Slider.Value) default to TwoWay mode without needing explicit Mode=TwoWay.
- UpdateSourceTrigger controls timing: PropertyChanged updates immediately, while TextBox.Text defaults to LostFocus.
- Guard clauses comparing new and old values in a setter prevent redundant notification cycles and potential feedback loops.
- IDataErrorInfo and INotifyDataErrorInfo let the binding engine surface validation errors without the setter throwing exceptions.
- Live validation via PropertyChanged trades responsiveness for potential performance cost if the setter does expensive work.
- Understanding default modes per control type avoids surprises when debugging why an edit isn't reaching the ViewModel.
Practice what you learned
1. What does UpdateSourceTrigger control in a TwoWay binding?
2. What is the default UpdateSourceTrigger for TextBox.Text in WPF?
3. Why is a guard clause like 'if (_email == value) return;' useful in a bound property setter?
4. What is the primary purpose of implementing INotifyDataErrorInfo on a ViewModel?
5. What is a potential downside of setting UpdateSourceTrigger=PropertyChanged on a TextBox whose setter performs expensive validation?
Was this page helpful?
You May Also Like
Data Binding Fundamentals in MVVM
Learn how data binding connects UI elements to underlying data sources so views update automatically without manual synchronization code.
INotifyPropertyChanged
Understand the interface that powers change notification in MVVM, how it wires up data binding, and how to implement it efficiently.
Value Converters
Learn how IValueConverter and IMultiValueConverter transform data between ViewModel types and UI-friendly representations without polluting the ViewModel.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics