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

Question

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

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

Answer 1

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

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

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

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

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

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

Answer 2

Yup, каждый вид должен иметь свою модель ViewModel.

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

HTH.

Answer 3

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

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