Относительно ViewModel

Поскольку ваша модель идеально вписывается в ваше представление, т. е. ваше представление (диалоговое окно настроек) может напрямую связываться со структурами данных модели, вам повезло, что вам нужна модель представления.

Однако есть много других случаев, когда это не так: представьте, что у вас есть представление, которое является прямым отображением таблицы базы данных, но вам нужен пользовательский интерфейс, который не совсем соответствует этой абстракции.

Взяв ваш пример «диалога настроек», допустим, ваша модель напрямую сопоставляется с таблицей базы данных с полями setting_name, setting_value. Однако, с вашей точки зрения, вы не хотите, чтобы пользователь заполнял какую-либо сетку; скорее, вы хотите, чтобы пользователь заполнил некоторые поля «Имя пользователя», «Почтовый адрес» и т. д. В этом случае вы можете создать модель представления, которая предоставляет такие свойства, как UserName, MailAddress, и внутренне сопоставляет их с вашей моделью.

То, что вы считаете своей Моделью, на самом деле является вашей Моделью Представления. ViewModel — это класс, поддерживающий View. У него часто есть API, предназначенный для конкретной технологии (например, WPF или SilverLight).

Таким образом, ViewModel может иметь свойства ICommand и свойства, предоставляющие цвета или кисти для привязки данных. Он также может иметь свойства, которые определяют, включены или отключены определенные элементы управления или вообще видны.

Вся эта логика очень ориентирована на представление и, следовательно, живет в модели представления.

Во всех приложениях, кроме игрушечных, вам также нужна правильная модель предметной области, но вы не хотите загрязнять эту модель всей этой логикой, ориентированной на представление. Это не относится к этому - вы можете повторно использовать модель предметной области для предоставления веб-служб или веб-сайта, а свойства INotifyPropertyChanged, ICommand и многое другое не принадлежат им.

Модель предметной области — это ваша модель в шаблоне MVVM. Модель представления обеспечивает мост между представлением и моделью.

ViewModel обычно используется для привязки к тем значениям, которые влияют на внешний вид и поведение вашего представления. В этом конкретном случае вы должны дополнительно абстрагировать свою модель, чтобы представлять только данные настроек, а не поведение. Например, если у вас есть флажок, который при установке делает несколько ползунков недействительными, логика включения/отключения этих ползунков будет предоставлена ​​ViewModel, а не самим представлением и не самой моделью.

Один полезный способ взглянуть на разбиение ваших проектов на MVVM — спросить себя, как бы я провел модульное тестирование поведения моего представления, предполагая, что я не могу взаимодействовать с представлением из моего теста? Часто вы обнаружите, что большая часть вашего поведения на самом деле привязана к представлению и практически не поддается проверке, если не считать функциональных тестов.

Модель — это модель ваших данных. ViewModel – это модель вашего представления. Представление — это Window, Page или DataTemplate, обычно определяемое в XAML.

Существует тесная связь между представлением и моделью представления. Объекты в представлении привязаны к свойствам модели представления. Если вы измените дизайн представления, вы измените дизайн модели представления. Вообще говоря, модель представления — это то, что вы используете вместо кода программной части.

Существует тесная связь между моделью представления и моделью данных. Экземпляр модели представления обычно содержит ссылку на экземпляр модели данных. Свойства модели представления обновляют свойства в экземпляре модели данных, как правило, когда они установлены. (Хотя это не обязательно. Например, модель представления нередко реализует Command, который обновляет базовый экземпляр модели данных, или реализует IEditableObject.)

Между представлением и моделью нет связи. Как правило, вы можете вносить существенные изменения в модель, которые, если они не влияют на пользовательский интерфейс, также не требуют изменений в представлении. Как правило, вы можете вносить существенные изменения в функциональность пользовательского интерфейса, не затрагивая модель данных (если эти изменения действительно не требуют новых функций в модели данных).