Одна модель, несколько страниц -> несколько представлений?Несколько ViewModels?

Question

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

В реализации MVVM я предполагаю, что лучше всего MVVM рассматривать каждую страницу как отдельное представление.Это правильно?

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

Для иллюстрации:

Вариант 1

Class A (X, Y, Z)
ViewModelA1 (X)
ViewModelA2 (Y)
ViewModelA3 (Z)
View1 captures ViewModelA1
View2 captures ViewModelA2
View3 captures ViewModelA3

Вариант 2

Class A (X, Y, Z)
ViewModelA (X, Y, Z)
View1 captures ViewModelA.X
View2 captures ViewModelA.Y
View3 captures ViewModelA.Z

Answer 1

Слово «вид» говорит само за себя.Это представление данных.Задача ViewModel - сделать данные, поступающие с модели, презентабельными.Все, что необходимо сделать с данными, происходит в модели представления, чтобы представление могло это показать.

Обычно у вас есть отношение один к одному, которое вы просматриваете с моделями представления, потому что обычно вы хотите показывать эти данные только одним способом.(одно «представление»). Откуда я отклоняюсь от обычной практики (возможно, от шаблона MVP?), если вы хотите отображать данные несколькими различными способами (например, вам нужна гистограмма или линейный график, иликруговая диаграмма) и данные одинаковы для всех видов, тогда вам нужна только одна модель вида.Это случай принципа СУХОЙ.Если у вас есть три модели представления, и все они одинаковы, используйте одну модель.Несколько просмотров.Одна модель.

Answer 2

Соответствующие рекомендации, касающиеся MVVM, как меня учили (и практики):

• Каждая страница / представление имеет одну ViewModel.

• У ViewModel должны быть только те поля / свойства, которые имеют отношение к View, который их использует.

• ViewModel может быть соответствующим образом объединен из нескольких базовых логических моделей / классов.

Приведенное выше может привести к большему количеству моделей, но с ними легче работать со временем, так как изменения одного View / ViewModel не влияют на другие Views или ViewModels

Это соответствует вашему первый вариант .

Answer 3

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

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

Однако, у вас также может быть ситуация (как я делаю в моем текущем проекте), когда ViewModels должны справляться со сложными отношениями в базовой модели, и когда различные сущности модели могут обновляться с нескольких конечных точек (т.е. пользователь или дуплексный сервис WCF). В этом случае вы проводите много времени в каждой ViewModel, следя за тем, чтобы его данные были синхронизированы с базовыми моделями, и было бы глупо заново выполнять всю эту логику в каждой ViewModel. В этом сценарии я обнаружил, что самый чистый подход заключается в том, чтобы ваши ViewModels отображали более или менее 1: 1 с моделями и могли повторно использоваться в нескольких представлениях. Недостатком этого подхода является то, что в конечном итоге вы можете получить много специфичного для пользовательского интерфейса кода из различных различных представлений, смешанных в одном классе, что может затруднить его тестирование и сопровождение. (Да, я знаю, что ViewModels, как предполагается, не тесно связаны с каким-либо конкретным пользовательским интерфейсом, но вы по-прежнему получаете большой код, который фактически говорит: «Когда пользователь выполняет эту команду, привязанную к некоторому элементу пользовательского интерфейса, который я» Я притворяюсь, что ничего не знаю, делаю то, что я притворяюсь, что я не знаю, приведет к тому, что диалоговое окно будет поднято. "Даже на этом уровне абстракции логика, закодированная в ViewModel, может отличаться от Вид на вид.)

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

Что бы это ни стоило, одно из моих разочарований в большинстве статей о MVVM, а также то, что они имеют дело с чрезмерно упрощенными сценариями, которые не отражают сложность, с которой вы сталкиваетесь в реальном мире. Как только вы прошли через форму Customer -> Order -> OrderDetail, я обнаружил, что большинство прочитанных рекомендаций, как правило, ломаются, и я остаюсь в одиночестве.

Answer 4

Смотри, что ты спрашиваешь, это:
У меня есть 1 М.
У меня есть 3 Vs.(Предполагая, что для вас предпочтительнее создать 3 В).

Должен ли я иметь 1 ВМ или 3 ВМ ?? Другими словами Вы спрашиваете, , с какой стороны концепция виртуальной машины ближе ?На стороне М или V?

Исходя из моего опыта работы с шаблоном, виртуальная машина НАМНОГО более тесно связана с V.

Так что quick ответит на вашвопрос: 3 ВМ (вариант 1).Вариант 2 - неправильный способ думать об этом паттерне.

Answer 5

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

У меня также есть Задачи, в которых используется несколько ViewModels, управляемых Задачей через несколько Представлений.Например, создание учетной записи пользователя в приложении с использованием коллажей из нескольких сторонних учетных записей, таких как Facebook, Twitter и т. Д., Где у каждого стороннего API есть свой собственный набор требований, но он отображается как отдельная задача для пользователя через серию шагов.Ориентирован на учетную запись пользователя.

Шаблон MVVM является гибким в зависимости от необходимости.Определите задачу, разбейте ее и решите, какая из них лучше всего подходит.

Answer 6

Вариант 1 - лучшая модель для использования.

Я не уверен, что вы имеете в виду под X, Y и Z.

Вы должны просто передать один и тот же экземпляр модели каждой ViewModel

Class Model
{
  string X { get;set;}
  string Y { get;set;}
  int Z { get;set;}
}

Class MainViewModel
{
  // constructor
  ViewModel()
  {
    model = new Model()
    SubViewModel = new SubViewModel(model);
  }

  Model model {get;set;}
  SubViewModel sub { get;set;}

}

Class SubViewModel
{
  // ctor
  SubViewModel(Model model)
  {
    this.model = model;
  }

  Model model { get;set;}
}

MainViewModel обрабатывает навигацию между каждым SubViewModel, но все они смотрят на один и тот же экземпляр модели, поэтому у них всех одинаковые данные.

Answer 7

В реализации MVVM я предполагаю, что лучше всего MVVM рассматривать каждую страницу как отдельное представление.Это правильно?

Да, я бы сделал это в зависимости от сложности.Я думаю, что MVVM для большинства приложений WP7 - это просто излишество.