Пусть есть иерархическая модель (модель, состоящая из других моделей) - Model3 в коде ниже. Как сделать для этой модели модель представления? При этом эта модель представления должна представлять в виде своих свойств не свойства нижележащих моделей представления, а сами эти нижележащие модели представления.

Мой вариант показан в коде ниже как ViewModel3. На закомментированный код прошу пока не обращать внимания. Проблема в нём в том, что этот вариант содержит дублирование данных. ViewModel3 содержит не только Model3, которая содержит Model1 и Model2, но и ViewModel1 и ViewModel2, которые тоже содержат Model1 и Model2. В результате, при изменении свойства ViewModel1 (которое принадлежит ViewModel3) я должен не только изменить поле vm1, лежащее в основе этого свойства, но и поле m3. Это нужно сделать потому, что логика изменения ViewModel3 подразумевает отображение этих изменений на Model3. Т. е. главное, это изменить свойства Model3, лежащей в основе - не зря эта модель передаётся в конструкторе. Изменить Model3 (в виде поля m3) я могу либо изменив все свойства соответствующей модели m1, представляющей поле m3:




либо изменив саму эту модель:
закомментированный код



Минус тут в том, что я должен в любом случае изменить ещё и поле vm1, т. к. иначе произошедшие изменения в m3 не отобразятся в соответствующих представлениях для vm1, которые отображают часть данных из m3 по логике вещей.

Так вот, у меня такое ощущение, что у меня неправильный дизайн. Кажется, лишним является создание в конструкторе ViewModel3:




Или, может, лишним является хранение модели Model3



?

Из-за этого появляется дублирование данных и я должен в каждом сеттере делать два изменения - для каждого свойства составной модели и для каждого свойства в виде отдельной модели представления. При этом реально нужные изменения - только для модели (у меня это Model3 m3), а изменения для ViewModel1 vm1 - только для отображения результата.

Есть какой-нибудь лучший подход?

авторлибо изменив саму эту модель:
закомментированный код


Тут ещё проблема в том, что, чтобы это работало, модель представления ViewModel1 должна предоставить свою модель Model1, лежащую в основе, что отображено у меня в закомментированном коде ViewModel1. Т. е. ещё один костыль.

James Bond FRuser7320Есть какой-нибудь лучший подход?

Есть, перестать тренироваться "на кошках", поставить перед собой реальную задачу и ее решить! Только так до Вас дойдет, что ЧИСТЫЙ MVVM это один большой костыль, который в реальный проектах НЕЖИЗНЕСПОСОБЕН!
Да. Я начитался статей типа этой . В них предлагается делать четырёх-, пяти- и более слоевые конструкции. Авторы подобных статей бодро говорят, как у них с такими конструкциями всё выходит гладко и чисто. Только у меня сомнения закрадывается, что если в трёх слоях уже многие путаются, то когда намешано 4 слоя и более, да ещё дело касается крупных приложений, типа того же Офиса или Автокада, то всё становится ещё хуже. Авторы почти никогда не говорят, какой сложности были у них проекты. Может, это сраные мессенджеры и проверяльщики статусиков во вконтактиках?

У вас вот какие подходы для борьбы с MVVM?

user7320У вас вот какие подходы для борьбы с MVVM?
Неправильно спросил. Я хотел спросить, что бы вы предложили мне в моём случае? Модель, состоящая из двух других моделей. В представлении это должно быть представлено так:

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

Для меня логично было сделать модель представления для таких представлений в виде такой же включающей еирархии - VM3 имеет поля в виде VM1 и VM2.

Алексей Кuser7320Есть какой-нибудь лучший подход?а525...

1. Читать Фаулер "Рефакторинг".

2. Данные хранить в модели как она есть. Модель лучше сразу приспособить для датабиндинга, чтобы не писать потом для неё обёртки.

3. Логику разместить в UserControl code-behind. Если возникают проблемы с повторным использованием логики в code-behind, то выносить логику в отдельный класс (выделение класса по Фаулеру). Логику оформлять в виде ICommand или EventHandler, в зависимости от потребностей.

Начни с этого. Дальше сам всё поймёшь. Верь мне...
Don't you wanna say MVVM is sucks? B...b...but these and those guys say MVVM is fucking great... Okay

Алексей Кuser7320
Привязывай контролы непосредственно к этой структуре данных. Обёртки не нужны.
Я хочу свою работу как портфолио использовать в том числе. Как считаешь, что следует писать в резюме - "умею в MVVM" или не стоит?

мсущкоАлексей К3. Логику разместить в UserControl code-behind.
Нет.

Алексей КЛогику оформлять в виде ICommand.
Да.
В логике проблем нет. Проблема в в том, как представить иерархические модели в моделях представления в рамках WPF's MVVM. Я гуглил-гуглил, ничего толкового не нашёл.

Иерархические модели представления в WPF хороши тем, что в представлениях они выглядят как контейнеры, которые состоят из контент презентеров, которые ссылаются на дата темплиты - и всё выглядит логично.

James Bond FRАлексей К2. Данные хранить в модели как она есть. Модель лучше сразу приспособить для датабиндинга, чтобы не писать потом для неё обёртки.

Оч интересно, а как енто "приспособить для датабиндинга"?
Я думаю, он имел ввиду OnPropertyChanged и т. п.

мсущкоuser7320В логике проблем нет. Проблема в в том, как представить иерархические модели в моделях представления в рамках WPF's MVVM. Я гуглил-гуглил, ничего толкового не нашёл.
Я тебе в соседней теме давал рецепт, там всё есть. Всё работает на штатном HierarchicalDataTemplate. Модель классическая:



Я уже не про дерево говорю в этой теме.

Наверное, вас смутило слово "иерархические". Но в примере в первом посте видно, что у меня не дерево. Иерархия заключается во включении - т. е. одна модель представления является полем или свойством в другой модели представления.

Вот в чём вопрос.

Алексей Квдогонку: По сути, предлагается завести под логику в ICommand-ах отдельную ViewModel, если разместить это в code-behind религия не позволяет.
Зачем заводить два файла с кодом вместо одного?

И почему логика только в командах? А в свойствах? А в OnPropertyChanged?

Алексей Кuser7320Иерархические модели представления в WPF хороши тем, что в представлениях они выглядят как контейнеры, которые состоят из контент презентеров, которые ссылаются на дата темплиты - и всё выглядит логично.У тебя проблема в первую очередь из-за того, что ты смешиваешь в одних классах логику и данные. Помни:

1. Биндинг можно делать через RelativeSource.
2. У ICommand есть CommandParameter, в который можно передать SelectedItem какого-либо контрола.

И в данном случае даже пофиг, живёт логика в code-behind или где-то ещё.
А предложить подход в рамках MVVM кто-нибудь может?

Там всего-то дублирование данных у меня (мой пример кто-нибудь смотрел?). У меня такое ощущение, что я просто не так классы написал и что в рамках MVVM там должно всё разруливаться.

Алексей Кuser7320пропущено...

А предложить подход в рамках MVVM кто-нибудь может?

Там всего-то дублирование данных у меня (мой пример кто-нибудь смотрел?). У меня такое ощущение, что я просто не так классы написал и что в рамках MVVM там должно всё разруливаться.А чем это не MVVM?
"Обычно" модель представления (МП) "пробрасывает" данные модели в представление. Т. е. в свойствах МП в геттерах делается вызов свойств модели и результат возвращается:

get { return model.Property; }

В сеттерах же точно также присваивается значение не свойству МП, а по сути свойству М (модели):

set { model.Property = value; }

Т. е. в МП модель является backing field, хранящим свойства МП.

Но это для простых случаев - когда нет никакой иерархии в моделях и моделях представлений.

А когда иерархия, то ни в каких джошесмитовских букварях ничего такого не разобрано. И вообще нигде не разобрано. А я задал ПРОСТОЙ ВОПРОС: модель, у которой поля - другие модели. Как для неё сделать МП с таким же включением - МП, с полями в виде других МП?

У меня получилось так





Здесь данные дублируются, а не пробрасываются. При этом М по-прежнему является backing field:

private Model3 m3;

Но ведь надо ещё и модели Model1 и Model2 как-то представлять. Поэтому для них ещё по полю создаю - vm1 и vm2. И в каждом таком поле тоже хранится по копии модели. Итого уже две копии каждой из составляющих моделей хранится во ViewModel3. Например, модель Model1 хранится - одна в

private Model3 m3

в виде m3.M1, а другая - в

private ViewModel1 vm1;

в виде vm1.m1.

Теперь когда у меня прилетает новая ViewModel1 в сеттер ViewModel3, я должен обновить модель и там, и там.

В результате сеттер превращается не в простое




а в монструозное и костыльное




Причём никакие эти про такие проблемы не пишут. Я так понимаю, что они знают какой-то секрет или для них настолько элементарно представить мои иерархические модели в моделях представления, что они даже не считают нужным про этом упомянуть. Бубнят про какие-то слои, про "слишком много логики в VM", а про то, с чем должны сталкиваться каждый день и что я привёл - ни слова.