Довідка зі складним 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: Кілька переглядів оновлених на основі активної кімнати. Помітьте управління вкладками

Малюнок 2: Різне активне приміщення. Оновлено кілька переглядів. Елементи керування вкладками змінюються залежно від властивості об'єкта.

Малюнок 3: Різний тип вибору. Цілі зміни в перегляді

Щоб відповісти на питання, так, у кожного представлення повинна бути своя модель перегляду. Але не потрібно моделювати всю ієрархію. Тільки те, що потрібно перегляду.

Проблема, з якою у мене виникло більшість інтернет-ресурсів щодо MVVM:

У більшості прикладів Вид - це майже 1-на-1 відображення моделі. Але в моєму сценарії, де існують різні погляди на різні аспекти однієї моделі, я опиняюся між двома варіантами:

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

Або одна модель перегляду для кожного перегляду

Але обидва не є ідеальними.

Модель, орієнтована на модель (MVM), хоч і мала дублювання коду, є кошмаром для підтримки

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

Зрештою, я вирішив, що мати один VM на перегляд простіше в обслуговуванні та кодуванні, тому я пішов із підходом VVM.

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

У цій заключній формі клас моделей загального виду складається в кожен VVM.

Звичайно, мені все ж належить вирішити, що вважається загальним / спеціалізованим. І коли вигляд додається / об'єднується / видаляється, цей баланс змінюється.

Але приємна річ у тому, що я зараз в змозі підштовхувати / зменшувати членів від загального до VVM і навпаки легко.

І коротка примітка щодо синхронізації об'єктів:

Маючи загальну модель перегляду, це забезпечує більшу частину цього. Кожен VVM може просто мати посилання на ту саму загальну модель перегляду.

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

А для дійсно складних подій (тобто несподіваних каскадних оновлень) я перейшов би на використання Посередника.

Я не цураюся коду, коли дитина має зворотну посилання на свого батька. Все, щоб привести код в дію.

І якщо з’явиться можливість рефактора, я б скористався цим.

Уроки, які я засвоїв:

1. Некрасивий / робочий код> Красивий / неробочий код
2. Легше об’єднати кілька малих класів, ніж розбити величезний клас

Дивлячись на ваші макети, я б точно рекомендував створити ієрархію ViewModels та безліч маленьких представлень. І вам, швидше за все, доведеться моделювати зовсім трохи оригінальної ієрархії.

Щоб синхронізувати речі між ViewModels, використовуйте будь-які події або переглядайте властивості один одного між ViewModels. Синхронізація між переглядами та ViewModels повинна бути стандартними властивостями сповіщення.