Что касается ViewModel

Question

Я изо всех сил пытаюсь понять часть ViewModel шаблона MVVM . Мой текущий подход состоит в том, чтобы иметь класс без какой-либо логики (важно), за исключением того, что он реализует INotifyPropertyChanged . Класс - это просто набор свойств, структура, если хотите, описывающая как можно меньшую часть данных. Я считаю это моей моделью .

Большая часть кода WPF, который я пишу, является диалогами настроек, которые конфигурируют указанную модель. Код позади диалогового окна предоставляет свойство, которое возвращает экземпляр модели. В коде XAML я связываюсь со свойствами этого свойства, тем самым связываясь непосредственно со свойствами модели. Который работает довольно хорошо, так как он реализует INotifyPropertyChanged. Я считаю, что это диалоговое окно настроек: Просмотр .

Тем не менее, я действительно не смог понять, что же это за модель ViewModel. Прочитанные мною статьи предполагают, что ViewModel должен связывать View и Model вместе, предоставляя логику, которой не хватает в Model, но все еще сложную для перехода непосредственно в View. Это правильно? Будет ли в моем примере выделение кода диалогового окна настроек считаться ViewModel ?

Я просто чувствую себя немного растерянным и хотел бы, чтобы мои сверстники опровергли некоторые из моих предположений. Я совершенно не в курсе?

Answer 1

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

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

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

Answer 2

То, что вы считаете своей моделью , фактически является ViewModel . ViewModel - это класс, который поддерживает View. Он часто имеет API, предназначенный для конкретной технологии (например, WPF или SilverLight).

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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