Наверное я что-то не так делаю, куда копать? Пока дерево элементов статично, все вроде получается. Но в сложных формах приходится его динамически генерить, а не только при инициализации, но и в ходе работы программы. Приходится держать в ViewModel ссылку на View. Все сильно усложняется. Забить на MVVM, биндинг и делать как в WinForms? Не хотелось бы.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Вопрос по архитектуре, конкретно с этим кодом у меня проблем нет. Публикация конкретного кода тут сведется к обсуждению кривых рук автора, и ноль помощи по конкретному вопросу.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, s_aa, Вы писали:
S>>А код/xaml показать не судьба?
_>Вопрос по архитектуре, конкретно с этим кодом у меня проблем нет. Публикация конкретного кода тут сведется к обсуждению кривых рук автора, и ноль помощи по конкретному вопросу.
все там нормально в MVVM. вы конкретнее проблему опишите
MM>все там нормально в MVVM. вы конкретнее проблему опишите
Создал View, передал ему в качестве DataContext ViewModel. Во время работы программы срабатывает Command во ViewModel. Нужно перестроить дерево элементов во View. Как это сделать не имея во ViewModel ссылки на View?
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, s_aa, Вы писали:
MM>>все там нормально в MVVM. вы конкретнее проблему опишите
_>Создал View, передал ему в качестве DataContext ViewModel. Во время работы программы срабатывает Command во ViewModel. Нужно перестроить дерево элементов во View. Как это сделать не имея во ViewModel ссылки на View?
INotifyPropertyChanged и ObservableCollection делу не помогут?
Здравствуйте, s_aa, Вы писали:
_>срабатывает Command во ViewModel. перестроить дерево элементов во View.
Много способов. Идея заключается в том, чтобы разбить View (повторяющиеся и динамические части), каждая часть отрисовуется соответствующей ViewModel, используя data template или используя специальное свойсвто какого-либо элемента, DataTemplateSelector, DataTrigger в стиле с подменой ControlTemplate и тд.
_> Публикация конкретного кода тут сведется к обсуждению кривых рук автора, и ноль помощи по конкретному вопросу
Был опыт? Или почему так не оптимистично?
Все ошибаются. Не пытайтесь скрывать ваш код. Самый быстрый способ научиться — это когда кто-то исправляет ваши же ошибки.
Причина плохого отношения чаще всего заключается в вопросе. На StackOverflow даже ввели голосование, чтобы плохие вопросы автоматизированно закрывать, потому что это — большая проблема.
Ваш вопрос был бы закрыт как "too broad". Потому что "хороший" ответ должен рассказать обо всех способах и нюансах, что по сути выльется в небольшую (или же большую) статью. Или же вообще как оффтопик, потому что вы жалуетесь, что некий код не работает, а код не показываете.
Покажите код, обьясните четко, что происходит и как вы хотите — и любой специалист покажет вам одно из оптимальных для заданных условий решение. Без заданных условий, как вы понимаете, решений — множество.
Здравствуйте, s_aa, Вы писали:
MM>>все там нормально в MVVM. вы конкретнее проблему опишите
_>Создал View, передал ему в качестве DataContext ViewModel. Во время работы программы срабатывает Command во ViewModel. Нужно перестроить дерево элементов во View. Как это сделать не имея во ViewModel ссылки на View?
Вьюшное дерево должно строиться на основе какого-то свойства внутри viewmodel. Обновляем свойство — волшебным образом обновится и дерево (INotifyPropertyChanged-машинерия, вокруг которой каждый MVVM оборачивает свою иерархию базовых классов).
MD>Вьюшное дерево должно строиться на основе какого-то свойства внутри viewmodel. Обновляем свойство — волшебным образом обновится и дерево (INotifyPropertyChanged-машинерия, вокруг которой каждый MVVM оборачивает свою иерархию базовых классов).
Спасибо кэп. Поправочка "уже существующее дерево". А если одни элементы надо удалить, другие добавить?
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
S>Много способов. Идея заключается в том, чтобы разбить View (повторяющиеся и динамические части), каждая часть отрисовуется соответствующей ViewModel, используя data template или используя специальное свойсвто какого-либо элемента, DataTemplateSelector, DataTrigger в стиле с подменой ControlTemplate и тд.
Кое на какие мысли навели, буду думать спасибо.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, s_aa, Вы писали:
S>>Много способов. Идея заключается в том, чтобы разбить View (повторяющиеся и динамические части), каждая часть отрисовуется соответствующей ViewModel, используя data template или используя специальное свойсвто какого-либо элемента, DataTemplateSelector, DataTrigger в стиле с подменой ControlTemplate и тд.
_>Кое на какие мысли навели, буду думать спасибо.
Главные 3 вещи в WPF:
1. Байдинг
2. Как уже сказали data template и DataTemplateSelector
3. value converter
Этого практически достаточно, что бы сделать любой интерфейс, иногда только есть необходимость добавить элементам дополнительные свойства зависимости. Еще добавлю, что data template может так же содержать data template и использовать свой DataTemplateSelector, т.е. они могут быть вложенными друг в друга.
Здравствуйте, s_aa, Вы писали:
MD>>Вьюшное дерево должно строиться на основе какого-то свойства внутри viewmodel. Обновляем свойство — волшебным образом обновится и дерево (INotifyPropertyChanged-машинерия, вокруг которой каждый MVVM оборачивает свою иерархию базовых классов).
_>Спасибо кэп. Поправочка "уже существующее дерево". А если одни элементы надо удалить, другие добавить?
Здравствуйте, s_aa, Вы писали:
_>Спасибо кэп. Поправочка "уже существующее дерево". А если одни элементы надо удалить, другие добавить?
А какая разница? Или Вы и создаёте его тоже ручками во вьюху? Так это не mvvm ни разу.
1) Делаем проперти у вьюмодели, проперти содержит необходимую иерархию элементов (возможно, тоже вьюмоделей, исходя из задачи)
2) Вьюха биндится к этому проперти. И как именно вьюха будет визуализировать контент — нашей вьюмодели глубоко фиолетово. Сколько и каких таких вьюх забиндилось на это проперти — нашей вьюмодели тоже глубоко фи.
Каждая вьюмодель отображает проперти так, как хочет. Это может быть дерево, или грид для элементов лишь верхнего уровня, или просто циферка, отображающая общее число элементов в этой иерархии, или максимальную глубину иерархии, и т.п.
1) Используешь библиотеку MVVMLight
2) Наследуешь свою ViewModel от ViewModelBase
3) В свойствах которые биндятся вызывается функцию RaisePropertyChanged()
4) В качестве команд используешь RelayCommand из пространства имен GalaSoft.MvvmLight.Wpf
5) Коллекцию объектов помещаешь в ObservableCollection
6) Этой коллекцией инициализируешь ListCollectionView который биндишь к ItemsSource. Для обновления вызываешь функцию Refresh.
7) Для элементов дерева можно создать отдельно иерархию объектов где базовый наследуется от ViewModelBase. Там же можно добавить такие свойства такие как, например, IsExpanded которые будут биндится к ItemContainerStyle.
Здравствуйте, s_aa, Вы писали:
_>Приходится держать в ViewModel ссылку на View. Все сильно усложняется. Забить на MVVM, биндинг и делать как в WinForms? Не хотелось бы.
ViewModel может общаться с View через события. Т.о. вью дергает методы вьюмодели, а вьюмодель генерит события. Все, двунаправленая связь есть.
Держать вью во вью модели — плохо, потому что вьюмодель не должна ничего знать о вью. На то она и ВЬЮ-модель.
Но если подумать то и это не совсем верно. Плохо ни то что вьюмодель держит вью. А то что она Знает про конкретный вью. Вот этого нельзя допускать.
Последнее время я для себя придумал патерн, что у вьюмоделей делаю свойство
object View {get;set;}
Т.о. вьюмодель по прежнему ничего не знает про вью. Принцип MVVM не нарушен. Но это дает много преимуществ на стороне вью.
Например у каждого вью есть какой то вью-контекст выше уровнем. И тогда получить вью по вьюмодели очень просто. Нет нужды какие то словари вести.
Еще способ. На уровне вьюмоделей вы сами можете абстрагироваться от вью тем интерфейсом какой сочтете нужным.
interface IView
{
//все нужные фичи которые вьюмодель требует от вью.
}
Так вы тоже не нарушите принцип что "вьюмодель не знает про вью".
