Быстрый старт с WPF. Часть 1. Привязка, INotifyPropertyChanged и MVVM

Посмотрите в сторону ReactiveUI фреймворка. Намного интереснее будет повторять.

Спасибо за статью. Очень вовремя подошла. Буду ждать следующие.

Модель сейчас можно уже расписывать немного по другому, для экономия места

private void NotifyPropertyChanged([CallerMemberName] string propertyName = "")
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }

        protected bool SetField<T>(ref T field, T value, [CallerMemberName] string propertyName = null)
        {
            if (EqualityComparer<T>.Default.Equals(field, value)) return false;
            field = value;
            NotifyPropertyChanged(propertyName);
            return true;
        }

        public string Id
        {
            get => _id;
            set => SetField(ref _id, value);
        }

Хорошая статья. Но только… где Model от «первой буковки» паттерна? )))

Чтоб уж полностью соответстовать паттерну, то View и задание DataContext лучше производить в App.xaml.cs, а то в данном случае получается, что View создает VM. Ну или использовать какой нибудь фреймворк (caliburn.micro/MVVMLight)

Если не считать нарушения паттерна MVVM, статья неплоха. Сам смысл MVVM заключается в отделении данных от логики и представления, а у вас получается Model скрещена с ViewModel и уведомляет об изменениях сама себя.

Странно говорить о Model-View-ViewModel, не используя Model.

Хотел тут написать про MVVMLight и забивании на велосипеды. Но авторы вооще ребята, к успеху идут, выпилили документацию и впаривают курсы.

Grid — позволяет организовать элементы по столбцам и строкам, ширина каждого столбца или строки настраивается индивидуально.

Кажется, вы пропустили "в виде сетки или таблицы" и не только ширина, но и высота тоже ;)

MVVM и интерфейс INotifyPropertyChanged. Копия текста.

Копия текста?

Привязка в терминологии WPF — это механизм, позволяющий связывать некоторые свойства контролов с некоторыми свойствами объекта C#-класса и выполнять взаимное обновление этих свойств при изменении одной из частей связки (это может работать в одну, в другую или в обе стороны сразу).

Не обязательно C# класса. WPF может прекрасно подружиться с F#, не говоря уже о VB.Net.

Ну, почти всё, финишная прямая! Осталось указать вьюхе, что оно должно слушать событие PropertyChanged:
TextBox Text="{Binding Path=SynchronizedText, UpdateSourceTrigger=PropertyChanged, Mode=OneWayToSource}"
TextBlock Text="{Binding Path=SynchronizedText, UpdateSourceTrigger=PropertyChanged, Mode=OneWay}"

Здесь, мне кажется, вы не совсем однозначно выражаетесь.

UpdateSourceTrigger лишь указывает на то, когда будет обновляться привязываемое свойство. PropertyChanged устанавливает режим обновления сразу после изменения свойства в "приемнике" (не самое удачное слово, но ничего лучше на ум так и не пришло). По умолчанию TextBox обновляет привязку после потери своего фокуса. Что касается TextBlock, то там установка UpdateSourceTrigger не требуется, как и явный Mode = OneWay.

В целом, несмотря на то, что хороших материалов по WPF хватает, еще один туториал точно не повредит.

Но в будущем мне бы хотелось, чтобы примеры были не настолько искусственные. В частности: здесь совсем не требуется реализация INotifyPropertyChanged. Если TextBlock должен дублировать текст из TextBox, то можно сразу там и привязываться к свойству Text, а дополнительная прослойка в виде свойства, оповещающего о своих изменениях, не нужна, обычного авто-свойства в данном конкретном случае будет достаточно.

Хорошая статья, будет интересна как для новичков так и для тех кто уже знаком с WPF, и хотели бы узнать о патерне MVVM.
Также мне кажется стоило бы указать что привязать DataContext можно сразу в XAML.

Статья хорошая, хорошо рассказана основа биндинга.

Есть несколько замечаний/предложений:
1) лучше не загромождать xaml необязательными атрибутами. Например, StackPanel легко обойдётся без Orientation=«Vertical», а оба биндинга справятся без указания Mode. К тому же, режим биндингов и так будет разный — у TextBox режим по умолчанию TwoWay, а у TextBlock — OneWay (как указано в настройках свойств зависимости Text этих классов).

2) Всё-таки лучше указывать датаконтекст в xaml-е, а не в конструкторе:

<Window ...
        xmlns:vm="clr-namespace:Ex1.ViewModels">
    <Window.DataContext>
        <vm:MainWindowViewModel/>
    </Window.DataContext>
    <StackPanel>
        ...
    </StackPanel>
</Window>

Как указали выше, суть не изменится, зато будет два плюса — показать, что в замле можно указывать всё что угодно, а также в редакторе заработает подсказка свойств в биндинге (лучше отметить, что при изменениях во вьюмодели нужно сбилдить проект). А во втором уроке можно будет рассказать про d:DataContext, опять же — для подсказок.

3) Базовый класс BaseViewModel лучше делать не сразу, а потом. В начале показать, что во вьюмодели должен быть INotifyPropertyChanged, а потом (во второй части) сделать рефакторинг и вынести в отдельный класс. Предполагаю, что эту статью будут читать новички, им будет полезно показывать по шагам, объясняя по ходу изменения в коде и показывая необходимость проводить рефакторинг.