Чи повинні ViewModel або View відповідати за створення нових представлень у MVVM?

11

У своєму додатку WPF я хочу створити новий вид. Де мені це зробити - у ViewModel або Model ?

Додаток - це (дуже простий на сьогоднішній день) формоподібний інструмент з одним вікном з однією кнопкою «відправити». У разі, якщо встановлено один із прапорців, з’явиться нове вікно, що використовує той самий ViewModel, щоб запитати у користувача додаткову інформацію. Для цілей цього питання розглянемо лише новий підхід до вікон, не розглядаючи інші підходи, такі як показана / прихована панель.

В ідеалі в View не повинно бути жодного коду. Крім того, оскільки View не має ніякої логіки в ньому, VM спочатку потрібно перевірити, чи потрібне створення нового перегляду, і - коли він є - відкидаючи цю відповідальність на View, що призводить до розмивання коду.

З іншого боку, створення нового перегляду в ViewModel порушує принцип, що ViewModel не повинен нічого знати про View.

Отже, чи краще створювати нові представлення даних у View чи ViewModel?

c# design wpf mvvm

— Mac70
джерело

1

Я не дуже розумію ваше запитання. Що означає "В режимі перегляду чи перегляду"? ViewModels не створюють представлення даних, а представлення, безумовно, не створюються самі.

— Роберт Харві

1

Я маю на увазі, який із цих шарів повинен відповідати за створення нових поглядів - сигнал для цього повинен надходити звідкись, коли відбувається дія. Я повністю виключив модель з цього питання, оскільки вона взагалі нічого не повинна знати про фронтенд.

— Mac70

Можливо, я правильно не розумію ваше питання, вони не повинні втручатися у ваш погляд. Якщо ви хотіли створити новий погляд у вашому viewModel, чи є якась причина, чому ви не використовуєте фрейми в xaml для зміни вмісту Window із прив’язкою до вашого поточного виду ViewModel?

— Сіобхан

8

Я використовую ін'єкційну залежність та IViewFactoryін'єкційну модель у вигляд, щоб дотримуватися обох обмежень.

ProductViewModel(Наприклад) викликає this.viewFactory.Show("Details", this)відкрити ProductDetailsViewз собою , як ProductViewModel. Він також може відкрити подання на основі іншої моделі перегляду с this.viewFactory.Show<ClientViewModel>().

Реалізація (насправді існує декілька для WinForms, простий Wpf Windows, оболонки Wpf з вкладками, ...) заснована на StructureMapконвенції. Перегляди позначають свою модель перегляду через IView<ProductViewModel>інтерфейс.

Отже модель перегляду нічого не знає про подання, крім його ролі (вид за замовчуванням, перегляд деталей, ...), а представлення не містить коду для створення іншого подання. Також моделі перегляду знаходяться в окремій збірці, яка не стосується жодної збірки Wpf.

— Філіп
джерело

7

Теоретична відповідь

Якщо у вас є ViewModel, дії з косметичним ефектом (наприклад, виділення предмета при наведенні миші) є завданням View, а дії, які мають "реальні" ефекти (наприклад, нерестування нового вікна) - це завдання ViewModel.

Таким чином, створення нового вікна є роботою для ViewModel. Однак ні View, ні ViewModelслід знати, як саме створити Вікно, це не входить до їх обов'язків і належить до іншого класу.

Ви можете стверджувати, що створення нового вікна - це робота для View. Хоча я не погоджуюсь, в таких дискусіях мало значення, адже на практиці це не кінець світу, якщо ви помістите цей код у View, а також перенести його ViewModelна пізніше . Важлива частина полягає в тому, що логіка створення нового вікна міститься в незалежному класі, як правило, якийсь WindowFactory. Сенс MVVM, MVP, MVC тощо полягає в тому, що у вас є класи з невеликими і чітко визначеними обов'язками. Ось чому ви не додаєте додаткові обов'язки до View, ViewModelабо Modelякщо вам не потрібно.

Ні за яких обставин створення Window не належить до Model, тому що Modelвін навіть не усвідомлює, що є щось на зразок GUI.

Практична відповідь

Йдеться про "інструмент, що нагадує одну вікно, з однією кнопкою" відправити " . Отож ось безсоромна плагін для відповідної моєї відповіді: навіщо використовувати MVVM?

Підводячи підсумок, що говорить ця відповідь: Нехай це буде просто. О, і майте на увазі теоретичну відповідь вище, щоб реалізувати, як тільки ваше вікно однієї кнопки почне ускладнюватися.

— Петро
джерело