MVVM, Shared Model и паттерн Repository

#c_sharp #wpf #xaml #mvvm #шаблоны_проектирования

Имеется WPF MVVM приложение, отображающее геометрические фигуры (Shape) внутри полотна
(Canvas).

Упрощенная версия для простоты изложения:

Модель: 

class Canvas
{
    public List Shapes;
}

class Shape
{
    public int X;
    public int Y;
}


Имеется несколько ViewModel'ей, некоторые из них отображают данные выбранной фигуры
(фигура выбирается по клику на фигуру), некоторые - данные выбранного Canvas'а (выбирается
с помощью комбобокса в ToolbarView), некоторые - и то и другое.

Т.о. имеется CanvasViewModel, CanvasPropertiesViewModel, ShapePropertiesViewModel
, ToolbarViewModel.

ToolbarViewModel, CanvasViewModel и CanvasPropertiesViewModel связаны с текущим Canvas'ом.
ToolbarViewModel и ShapePropertiesViewModel связаны с выбранной фигурой.
ToolbarView, связанный с ToolbarViewModel, отображает большой плоский список названий
всех canvas'ов. 

Вопрос 1: как шарить между ViewModel'ми выбранную фигуру и выбранный canvas?
Пробовал через EventAggregator, но получается слишком много регистраций сообщений,
код становится не читаемый.

Вопрос 2: Кто должен отвечать за загрузку данных с сервера о canvas и его сохранение?
И где лучше разместить эту логику (может как-то использовать Repository)? (имеется
сторонний web сервис, который отдает и сохраняет данные о canvas)
    

Ответы

Ответ 1

Во-первых, если Canvas ещё как-то оправдано, то ToolbarViewModel — никак. Тулбар
— это подробность View, а смысл этой VM — корневые параметры отображения.

Таким образом, у нас получается class RootVM с ReadOnlyCollection Canvases
и DP CurrentCanvas. К которому легко прицепить комбобокс или там ListView.

Затем, я бы слил вместе CanvasViewModel и CanvasPropertiesViewModel, вроде бы они
отвечают за одну и ту же сущность.

Давайте посмотрим, кому из ваших VM реально нужен CurrentCanvas. ToolbarViewModel
содержит его. CanvasViewModel существует на каждый канвас, и знать о CurrentCanvas
вовсе не должна. И CanvasPropertiesViewModel мы слили с CanvasViewModel.

Проблема исчезла!



Теперь, о загрузке/выгрузке с сервера. За это отвечают модельные объекты (по классу
на Canvas и фигуру). Решение о загрузке-выгрузке принимает в любом случае бизнес-логика,
так что это она должна командовать модели произвести обмен информацией. Ну и на VM
лежит ответственность за синхронизацию данных с моделью.



Не бойтесь, чтобы одна VM отображалась в нескольких местах несколькими разными View,
причём по-разному. Это нормальная практика.