user7320user7320пропущено...

Там когда привязку делаешь, TreeViewItem автоматом генерится как обёртка над привязываемым значением из модели представления, вроде.
Я к тому, что TreeViewItem больше относится к генерации представления. Т. е. если охота вручную TreeViewItem добавлять, то в MVVM это лучше делать в коде поддержки - этакая вью-вью-модель.Я о том, что не надо самому писать аналог класса TreeViewItem со свойствами Content, IsExpanded, IsSelected и т. п.

user7320Ведь "аналог" класса TreeViewItem во VM не просто свойства такие содержит, но и логику по ленивой загрузке и прочую логику. Например, отрисовку крестика ("можно развернуть"), если айтим содержит потомков, или другого рисунка, если не содержит. Много чего ещё. А как "расширить" подобной функциональностью TreeViewItem?Я не говорил, что модель и HierarhicalDataTemplate не нужны. Всё что нет в TreeViewItem должно быть в модели. Но не надо пихать в модель то что есть в TreeViewItem, только если для этого есть особые причины.

user7320Я привязываю. У VM IsExpanded и у V IsExpanded - привязал.А зачем:
1. Добавить свойство в VM.
2. Добавить привязку данных V <=> VM.

Может проще дать логике ссылку на TreeViewItem? Разумеется, это не единственное решение, просто предлагаю об этом подумать. :-)

user7320Если вы дадите ВМ ссылку на В, то останется ли возможность привязывать несколько В к одной ВМ? Каким образом?Конечно, нет. Если требуется такая возможность - используй классический MVVM на здоровье. :-) Но часто ли это надо?
user7320И что станет со всеми этими словами "меньше связность - лучше тестирование"?Тестировать надо модель, а она, обычно, на сервере. Впрочем, "пилите, Шура, пилите, они золотые..." :-)

зы: Ещё раз обращаю внимание на фразу: "Это не единственное решение, просто предлагаю об этом подумать".

user7320Ладно, дайте ссылку, где у вас пример с привязкой ВМ ко В.Это не у меня, это в WPF. :-)

Это любой Control+ControlTemplate или UserControl.

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

user7320Алексей К Тут описана работа с окнами. Но я не пойму вопроса. Модели окон связываются наиболее удобным способом: свойствами, событиями или ещё как. В чём интрига? :-)
Да ни в чём. Я просто сделал не по правилам, и боялся, что кто-нибудь увидит и скажет ай-яй-яй. ))Забей на них. Делай как тебе сегодня удобнее. Не понравится - в новом проекте сделаешь "правильно". Заказчику пофиг как у тебя там написано, ему главное результат а не процесс.
user7320Ну, у вас примерно как у меня, только я сразу в DataContext данные пихаю, а не в метод-хелпер.Это да.

user7320А когда вы делаете "установку содержимого окна" через




вы можете потом из этого content свойства раскидать по привязкам в замл-разметке этого окна? Без установки DataContext?Могу, но это не требуется, поскольку Window является ContentControl-ом, и я в Window вставляю готовое содержимое. В самом Window у меня XAML-разметки нет.

user7320И это, вызов нескольких диалоговых окон одно из другого у вас нормально пройдёт?Да, проблем с этим никогда не было.