А у MVVM нет общих правил, каждый реализовывает его по-разному.
Ну я б не говорил, что их прям нет. Есть привязки, есть INotifyPropertyChanged, есть рекомендации от MS. Да, вы правы в том смысле, что WPF это библиотека, но НЕ фреймворк для разработки, т.е. она не регламентирует структуру приложения.
И у меня диссонанс — что сначала изучать, куда копать, что вообще делать, что стоит изучать, а что нет.
Вот
пару дней назад советовал книгу:
Raffaele Garofalo, "Building Enterprise Applicatio... - если ничего не читали еще, начните с неё.
И действительно хороших, многофункциональных и понятных проектов на WPF + MVVM я не видел.
Неудивительно: WPF-приложения это обычно line-of-business, а это не open-source по определению.
С чего начать изучение WPF?
Убедитесь, что более-менее понимаете платформу .NET и ООП в ней, иначе будет тяжело.
Вам надо будет разобраться:
а) с системой зависимых свойств (dependency property);
б) c MVVM и INotifyPropertyChanged;
в) само собой с XAML и контролами, принципами написания своих контролов;
г) со стилями и стилизацией;
д) с системой команд (ICommand) и прочим.
Нужны ли MVVM-фреймворки? Почему столько дискуссии возникает. Одни говорят да, другие — нет.
Дискуссии возникают потому что а) некоторые вещи можно сделать разными способами; б) разработчики имеют дело с приложениями разного размера и сложности, но редко об этом задумываются в спорах; в) опытные разработчики нередко сами себя уже обеспечили нужным "библиотечным" пока разрабатывали приложения (ViewModelBase, хах :) ). Лучше пока разберитесь сами как что работает, потом поймете, какой фреймворк вам пригодится.
Впоследствии еще советую познакомиться с IoC-контейнерами, если еще не пользовались. Это общий совет для крупных приложений, не только для WPF. Некоторые имеют спецальные интеграционные библиотеки для работы на пару с фреймворками, например
Autofac:
Prism.Autofac.
