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

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

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

Мои вопросы:

Должен ли я создать представление модели представления для каждого представления (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: Другой тип выбора. Весь вид изменений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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