Помощь со сложным MVVM (несколько просмотров)

Мне нужна помощь в создании моделей представления для следующего сценария:

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

введите описание изображения здесь

Мои вопросы:

Должен ли я создать представление модели представления для каждого представления (VM1, VM2 и т. Д.)?

1. Yes:
    a. Should I model the entire hierarchical relationship? (ie, SubVM1, HouseVM1, RoomVM1)
    b. How do I keep all hierarchies in sync? (e.g, adding/removing nodes)

2. No:
    a. Do I use a huge, single view model that caters for all views?

Вот пример одного представления

Рисунок 1. Обновление нескольких представлений в зависимости от активной комнаты. Элемент управления Tab Tab

введите описание изображения здесь

Рисунок 2: Другая активная комната. Несколько просмотров обновлены. Элементы управления вкладками изменены в зависимости от свойства объекта.

введите описание изображения здесь

Рисунок 3: Другой тип выбора. Весь вид изменений

введите описание изображения здесь

wpf mvvm

— jayars
источник

Кстати, что такое мульти-вид? опечатка?

— JensG

«Muli view» была опечаткой. Я имел в виду разные виды для одной и той же модели. Мой вопрос состоял в том, должен ли я перемоделировать / обернуть всю иерархию модели для каждого представления, чтобы каждая модель представления содержала только то, что нужно отдельному представлению? Или я должен создать единую иерархию модели представления, которая содержит свойства из всех представлений? С тех пор, как я разместил этот вопрос, мне (не) повезло, чтобы выяснить плюсы / минусы двух, трудный путь. Буду обновлять эту ветку в будущем с полной диагностикой моего опыта, когда все будет не так беспокойно.

— Jayars

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

— Csharls

@jsjslim Я вздрогнул, когда прочитал «синхронизировать все иерархии». Я подозреваю, что вы использовали мульти-просмотр, и я подозреваю, что вы пожалели об этом (но я ошибался раньше). Ради других читателей, у которых может возникнуть тот же вопрос, вы можете хотя бы дать нам быстрый (иш) ответ?

— Гай Шалнат,

@ guy-schalnat Мульти-просмотр был требованием. Моя проблема заключалась в попытке выяснить, как построить модели представления. Проект все еще продолжается, и я не могу найти время, чтобы написать полный анализ. Но в заключение: я должен был игнорировать структуру модели и сосредоточиться на взглядах. Сложность, с которой я столкнулся, была навязана самим собой: я так сильно хотел использовать привязку данных WPF, что зациклился. То, что я сделал в конце, было хорошо, старый "копировать / вставить / рефакторинг". Окончательный дизайн, который появился, был легким (небольшое повторение) и, что более важно, работал. Напишу полный анализ в будущем.

— Джаярс

Ответы:

Чтобы ответить на вопрос, да, у каждого представления должна быть своя модель представления. Но нет необходимости моделировать всю иерархию. Только то, что нужно мнению.

У меня возникла проблема с большинством онлайн-ресурсов, касающихся MVVM:

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

Одна модель монолитного представления, которая используется всеми другими моделями представления

Или одна модель представления для каждого представления

Но оба не идеальны.

Модель ориентированного на модель представления (MVM), несмотря на низкий уровень дублирования кода, является кошмаром для обслуживания

Модель представления с ориентацией на представление (VVM) создает узкоспециализированные классы для каждого представления, но содержит дубликаты.

В конце концов, я решил, что иметь одну ВМ на View проще в обслуживании и писать для кода, поэтому я остановился на подходе VVM.

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

В этой окончательной форме класс модели общего вида состоит из каждого VVM.

Конечно, мне еще предстоит решить, что считать общим / специализированным. И когда представление добавляется / объединяется / удаляется, этот баланс меняется.

Но самое приятное в этом то, что теперь я могу перемещать элементы вверх / вниз от общего к VVM и наоборот.

И быстрое замечание относительно синхронизации объектов:

Наличие модели общего вида решает большую часть этого. Каждый VVM может просто иметь ссылку на одну и ту же модель общего вида.

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

А для действительно сложных событий (например, неожиданных каскадных обновлений) я бы переключился на использование посредника.

Я не уклоняюсь от кода, где у ребенка есть обратная ссылка на его родителя. Что-нибудь, чтобы код работал.

И если бы появилась возможность рефакторинга, я бы ее использовал.

Уроки, которые я выучил:

Гадкий / Рабочий код> Красивый / Нерабочий код
Проще объединить несколько маленьких классов, чем разбить огромный класс

— jayars
источник

Я бы хотел, чтобы я проголосовал за это дважды. Это одно из самых ясных объяснений вариантов, которые я видел.

— Умный Человек

Глядя на ваши макеты, я бы определенно рекомендовал создать иерархию ViewModels и множество маленьких View. И вам, скорее всего, придется смоделировать довольно немного исходной иерархии.

Чтобы синхронизировать вещи между ViewModels, используйте события или имейте свойства друг другу между ViewModels. Синхронизация между представлениями и моделями представления должна быть стандартными уведомляющими свойствами.

— Euphoric
источник