С MVVM, у каждого окна пользовательского интерфейса есть своя ViewModel?

Question

Когда я проектирую несколько представлений в соответствии с шаблоном MVVM, получает ли каждое представление свою собственную модель представления или все они используют одну и ту же? Я понимаю, что это в конечном итоге гибкое решение, но какова лучшая практика?

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

Answer 1

Для меня это субъективное утверждение - учебник, я бы сказал однозначно спаривание 1-1 - и, конечно, нет ничего плохого в том, что мы проактивны и устанавливаем парадигму, имея 1-1.Тем не менее, если у вас есть несколько представлений, каждое из которых представляет собой фрагмент одних и тех же данных, вам необязательно иметь по 1 - вы можете повторно использовать одно и то же в нескольких представлениях, пока не получите отклонение.Цель модели представления в том, чтобы стать мостом между пользовательским интерфейсом и бизнес-уровнем ... если бизнес-функции одинаковы, у вас либо будет общий интерфейс модели базы, либо базовая база данных, и вы будете реплицироватьодна и та же логика несколько раз.Если вид - это единственное, что изменяется, я не вижу проблем в повторном использовании одной и той же модели вида, пока не произойдет отклонение.

В wpf вы должны привязываться к значениям модели, если только в вашей модели представления нет ссылки на конкретное представление, которое не должно вызывать проблем.Даже если вы это сделаете, вы можете абстрагироваться от контракта (интерфейса) представления и вместо этого изменить свойство на этот тип.

Answer 2

Да, в принципе идея заключается в том, что ваша viewModel должна использоваться только одним представлением. Если вы используете viewModel для заполнения области (как в ASP.NET MVC), то эта viewModel будет «повторно использоваться» каждый раз, когда это представление представлено в разных местах.

Эта статья является обсуждением Джошом Смитом паттерна MVVM. Затем Уорд Белл обсуждает в этой статье , что, по его мнению, Джош не учел, утверждая, что работа Джоша все еще очень сильна.

Уорд отлично справляется со сложностью этого паттерна и показывает существующее напряжение. Вот его взгляд на напряжение:

По моему опыту, существует «диалог» между дизайном View и ViewModel. ВМ существует, чтобы служить представлению, даже если оно стремится к независимости от какого-либо конкретного конкретного представления. ВМ бесполезна, если нет представления, которое будет с ней работать; ясно, что разработчик виртуальной машины должен прислушайтесь к замечаниям разработчика View.

С другой стороны, в бизнес-приложениях императивы приложения - то, что представление должно делать для удовлетворения бизнес-требований - входят в компетенцию программиста и> лучше всего определяются возможностями ViewModel.

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

Answer 3

Да, у каждого представления должна быть своя ViewModel.

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

НТН.