Как работает система привязки данных (Data Binding) в WPF?

А, Data Binding в WPF, ну это же просто песня, а не технология, если её правильно понять, а не пытаться ебать гвозди микроскопом.

Смотри, представь себе такую хуйню: у тебя есть твой интерфейс — это кнопки, текстбоксы, вся эта мишура. И есть твои данные — какой-нибудь объект, где лежит имя пользователя, флажок «согласен с правилами» и прочая лабуда. Так вот, блядь, привязка — это волшебная резинка, которая намертво связывает свойство в интерфейсе (например, текст в поле) со свойством в твоём объекте данных. Изменил объект — интерфейс сам обновился, ёпта! Вписал что-то в поле — и объект тут же получил новое значение. Красота!

Из чего эта магия состоит, если по-простому:

• Источник (Source): Это твой объект, твои данные. Обычный класс на C#. Но есть нюанс, блядь! Чтобы система привязки поняла, что свойство изменилось, и побежала обновлять интерфейс, объект должен крикнуть об этом. Для этого он реализует интерфейс INotifyPropertyChanged. Без этого — нихуя не заработает, интерфейс будет висеть, как будто ничего не поменялось.
• Цель (Target): Это свойство элемента управления в WPF. Важный момент — оно должно быть свойством зависимости (DependencyProperty). Но не парься, все стандартные свойства типа TextBox.Text или Button.IsEnabled уже такие.
• Сам объект Binding: Это и есть та самая резинка, настройка. В XAML она в фигурных скобках пишется.
• Конвертер (IValueConverter): Ну, иногда данные не совпадают. В объекте у тебя bool, а в интерфейсе надо показать Visibility — Visible или Collapsed. Вот конвертер — это такой переводчик, который говорит: «О, true? Значит, показываем! false? Пиздуй нахуй, скрываем!».

Вот тебе живой пример, как это всё встаёт раком и работает:

<!-- Вот наш TextBox. Свойство Text (цель) привязано к чему? К UserName! -->
<TextBox Text="{Binding Path=UserName, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />

А теперь смотри, что за объект стоит за этим:

// Это наш источник данных, ViewModel. Он должен орать на всю систему о своих изменениях.
public class UserViewModel : INotifyPropertyChanged
{
    private string _userName;
    public string UserName
    {
        get { return _userName; }
        set
        {
            // Проверяем, а реально ли значение поменялось? Чтобы не орать по пустякам.
            if (_userName != value)
            {
                _userName = value;
                // А ВОТ И КРИК! Самое главное, блядь! Без этого вызова — тишина и мертвый интерфейс.
                OnPropertyChanged(nameof(UserName));
            }
        }
    }

    // Это событие — система привязки на него подписывается ушами.
    public event PropertyChangedEventHandler PropertyChanged;

    // А это наш метод-крикун. Вызываем его, когда свойство изменилось.
    protected virtual void OnPropertyChanged(string propertyName)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

// И в коде окна мы говорим: «Окно, вот твой контекст данных, с ним и работай».
public MainWindow()
{
    InitializeComponent();
    this.DataContext = new UserViewModel(); // Всё, связь установлена!
}

Режимы привязки — это как настроить эту резинку:

• OneWay (По умолчанию для многих): Данные идут из источника в цель. Изменил объект — интерфейс обновился. Тыкнул в интерфейс — объекту похуй.
• TwoWay (Для редактируемых полей): Полная синхронизация. Изменил что-то в текстбоксе — объект обновился. Изменил объект в коде — текстбокс подхватил. Именно так работает пример выше.
• OneTime: Привязка-инвалид. Сработала один раз при старте и всё, на этом её миссия завершена. Дальнейшие изменения всем похуй.
• OneWayToSource: Инверсный уродец. Обновляет источник, когда меняется цель. Редко, но бывает нужно.

Ещё парочка важных пиздюлей, которые могут вылезти боком:

• Коллекции: Привязал ListBox к обычному List<T>, добавил в список элемент, а в интерфейсе нихуя? Так и будет! Для коллекций есть их специальный крикун — ObservableCollection<T>. Он орет не только когда свойства элементов меняются, но и когда саму коллекцию тронули (добавили/удалили элемент).
• Валидация: Можно сделать так, чтобы привязка проверяла, что пользователь ввёл не хуйню. Через IDataErrorInfo или свои правила.
• Отладка: Если привязка не работает и ты не понимаешь, почему — включи трассировку. В Output окне начнёт сыпаться информация, что куда идёт и где обосралось.

Вот эта вся система, если её использовать, и есть фундамент для нормального паттерна MVVM. Она позволяет не писать тонны кода в обработчиках кнопок, чтобы вытащить текст из поля и куда-то его сохранить. Всё связывается декларативно, в XAML, а логика живёт отдельно в своих классах. Когда врубаешься — жить становится проще, честное слово.