|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Всем привет, пишу приложение, стараясь придерживаться паттерна MVVM. Интерфейсно это приложение на весь экран с несколькими типами оконных форм. То есть существует текущая форма, которая в данный момент отображается на экране, и в зависимости от определенных условий она меняется на другую. View построил по следующему принципу: Есть MainWindow следующей структуры: Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
В качестве CurrentControl буду подставлять различные UserControl, которые представляют собой окна приложения. Для этого MainWindow создаю свою MainViewModel, которая будет управлять всеми окнами в приложении. Сначала создаю базовый класс ViewModelBase, от которого будут наследоваться все ViewModel приложения, чтобы реализовать интерфейс INotifyPropertyChanged. VB.NET Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
C# Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
Код MainViewModel VB.NET Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
C# Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
,где InputTabControl - UserControl.xaml со своей ViewModel- то есть стартовая форма приложения. При запуске приложения сначала создается MainViewModel, потом ViewModel для InputTabControl. Необходимо, чтобы из ViewModel для InputTabControl при определенных действиях можно было обратиться к MainViewModel и передать ей команду поменять CurrentControl для отображения другого UserControl. Вопрос- правильный ли подход я использую по навигации между окнами текущей задачи и как осуществить взаимодействие между различными ViewModel? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2016, 16:07 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
окно это и так ContentControl, какой смысл вкладывать ContentControl в ContentControl? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2016, 23:09 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman Mejtes, xaml главного окна- Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Смысл в следующем: 1) Чтобы поменять текущее окно, я в свойству CurrentControl для MainViewModel присвою другой UserControl, который содержит в себе код xaml разметку окна. Не уверен, что такой подход по навигации между окнами правильный. 2) Для дальнейшей возможности реализации меню в приложении. То есть в MainWindow будет область с элементами, которая все время видна, и будет область с ContentControl. При действиях с элементами в этой области меню содержимое ContentControl будет меняться. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 08:36 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_sub, вы хотите в модели представления хранить представление и подставлять его структуру главного окна? Что-то как-то замороченно и сомнительно. Попробуйте сделать так. В модели представления главного окна хранятся модель представления меню этого окна и модель представления для ContentControl. Смена содержимого CurrentControl происходит через отдачу команды из представления меню в модель представления меню, которая изменяет модель представления для CurrentControl (назовём это "событие А"). Для каждой модели представления, которая будет в CurrentControl, сделайте своё представление в виде DataTemplate. Тогда при событии А нужное представление подставится в ContentControl автоматически. Возможно, модель представления меню главного окна стоит ввести в модель представления окна, чтобы можно было изменять содержимое ContentControl сразу в команде окна, а не городить какую-нибудь сигнальную систему и маршрутизацию между моделями пердставлений (меню и главного окна). ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 19:42 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Если непонятно, что почитайте, что такое MVVM - в WPF только с этим нормально и можно работать, ибо под это WPF заточен. В вашем случае можно даже без модели обойтись (я не знаю, что у вас за приложение), но то, что я описал выше, затрагивает как минимум связь модели представления и представления. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2016, 19:44 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssЧто-то как-то замороченно и сомнительно.Веский аргумент, ничего не скажешь... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 05:32 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей КARKssЧто-то как-то замороченно и сомнительно.Веский аргумент, ничего не скажешь... Как я понял, у него VM подставляет куски V. Это значит, что VM знает о V, тогда как по фен-шую этого быть не должно. Уже одно это говорит об "инновационном" подходе. Если бы это было от корифея, тогда ещё можно было подумать, что там да как - может, действительно что-то инновационное придумал. Но поскольку это от новичка в WPF, то создаётся впечатление о банальном незнании основ и построении сомнительных костылей. Ну а тебе как? Всё показалось понятным в пояснении vb_sub, и ты одобряешь его подход? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 06:46 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssНу а тебе как? Всё показалось понятным в пояснении vb_sub, и ты одобряешь его подход?Я о том, что нужно оперировать фактами, а не абстрактными суждениями, основанными на современной моде. Каждый подход имеет свои преимущества и недостатки. Если единственным критерием качества является соответствие решения шаблону MVVM, то это просто глупо. Например, подход, приведённый ТС, имеет право на жизнь. Но его недостатком является то, что элемент, содержащийся в свойстве MainViewModel.CurrentControl, нельзя одновременно отобразить несколько раз. Этого недостатка лишены решения, основанные на DataTemplate. Преимуществом же такого подхода является его простота, решения через DataTemplate мне кажутся более многословными. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 08:33 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей КARKssНу а тебе как? Всё показалось понятным в пояснении vb_sub, и ты одобряешь его подход?Я о том, что нужно оперировать фактами, а не абстрактными суждениями, основанными на современной моде. Каждый подход имеет свои преимущества и недостатки. Если единственным критерием качества является соответствие решения шаблону MVVM, то это просто глупо. Просто WPF заточен под MVVM. По крайней мере, под его VM-V часть. У WPF для этого есть инфраструктура. А что-то самодельное всегда будет страдать отсутствием такой инфраструктуры и необходимостью всё написать самому, с соответствующими велосипедизмом, костылями и багами. И чем тебе не нравится MVVM? Его VM-V часть в WPF сделана просто отлично, а с помощью пары полезных подключаемых библиотек получается дополнительный функционал поведений и расширенные команды - вообще конфетка. Или тебе то, что вводится сущность VM кажется слишком громоздким? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 10:22 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей КНапример, подход, приведённый ТС, имеет право на жизнь. Но его недостатком является то, что элемент, содержащийся в свойстве MainViewModel.CurrentControl, нельзя одновременно отобразить несколько раз. Этого недостатка лишены решения, основанные на DataTemplate. Преимуществом же такого подхода является его простота, решения через DataTemplate мне кажутся более многословными. Это преимущество из разряда "кое-как работает на коленке". В других условиях - "шеф, всё пропало!". Один большой недостаток такого подхода - ТС приучится костыли подобные везде пихать, и будет попадать в кучу проблем, чуть шаг в сторону сделает. Ну и в нормальной разработке такой подход просто пошлёт куда подальше. Итого, где применим такой подход? В домашней наколеночной утилите "надо за 5 минут быстро что-то сварганить"? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 10:25 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssЭто преимущество из разряда "кое-как работает на коленке". В других условиях - "шеф, всё пропало!".Алексей КЯ о том, что нужно оперировать фактами, а не абстрактными суждениями, основанными на современной моде. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 11:03 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Проблема в том, что 95% учебного материала по WPF+ MVVM показано для приложений одного окна. Здесь все понятно и красиво. Но если у меня в приложении может быть 30 различных форм (view), причем они могут вызываться не только из меню, но и из друг друга, то гугление по "wpf mvvm multiple views in one window" приводит к миллиону различных вариантов- от включения в кода в code-behind до использования pages. Причем все это показано максимум на 3-5 различных формах внутри окна. То есть нет устоявшейся best-practice по данному вопросу. Если бы в Winforms я бы сделал эту операцию через 5 строчек Код: vbnet 1. 2. 3. 4. 5. 6.
, то в WPF это далеко не так очевидно. Я совершенно не спорю что мой код велосипедный, однако это единственное на мой взгляд что может заработать. Поэтому и создал пост, чтобы люди посоветовали как они справлялись с данной задачей или имеют какие-либо размышления. Насчет подхода с DataTemplate- если есть 30 различных view, то их нужно все включить изначально? Код: xml 1. 2. 3.
.......... Код: vbnet 1. 2. 3.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 11:14 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_subЯ совершенно не спорю что мой код велосипедный, однако это единственное на мой взгляд что может заработать.Не нужно недооценивать "традиционные" подходы, применяемые, например, в WinForms. В WPF они работают не хуже. vb_subесли есть 30 различных view, то их нужно все включить изначально?Если делать по MVVM-ному, то во ViewModel должен жить какой-то идентификатор текущей View. Во View "главной" формы можно вставить DataTrigger-ы или DataTemplateSelector. Если применять MVVM-ный подход, то я бы выбрал первый способ, с триггерами. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 11:35 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Архитектурно приложение выглядит как в примере ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 12:07 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей К, кстати, не так давно столкнулся с такой проблем :) примерно как вы описали. Когда используешь связку ViewModel + DataTemplate (которую я люблю), при "переоткрытии" окна с этой связкой или при переходе на другую страницу приложения и возрате на старую состояния определенный только на уровне View будут сброшены, так как визуальное дерево будет по шаблону отстроено заново. То, есть могут слететь выделения в ListBox'а, если они не синхронизированны с представлением коллекции и так далее. Так, что гонят на автора зря, не даром ContentPresenter представляет возможность отображения содержимого на основе шаблона или на основе содержиомого из готовых элементов. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 14:42 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_sub, есть 100500 примеров многооконных приложений в WPF, где можно вызвать открытие окна из любого слоя. Лично я использую самописное, у меня это примерно так работает: есть Standalone менеджер окон, в котором я вызываю метод OpenDialog или OpenWindow, а в качестве параметра передаю объект модели представления (viewmodel), WM ищет на основе типа модели стиль для окна, создает окно, применяет к нему этот стиль. То есть, для открытия окна мне нужно знать только модель представления. Так же после создания окна к нему сразу добавляются обработчики команд, на закрытие, подтверждения и прочее, чтоб связать это с моделью. В стиле окна я определяю шаблон окна, если нужно, параметры и прочее. Но есть и другие способы, не менее удобные. иногда, когда работаешь с WPF возникает ощущение, что некоторые вещи просто забыли сделать и забили на это основательно. На те же триггеры , которые нельзя определить в самом элементе управления, а можно только в стиле или в шаблоне. Где то читал, что вроде это недоработка и вот вот, это добят, а воз и ныне там :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 14:52 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman Mejtes, Roman Mejtes WM ищет на основе типа модели стиль для окна, создает окно, применяет к нему этот стиль то есть это практически тоже самое что уже стилизованный готовый UserControl, только более абстрактно? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 15:11 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_subПроблема в том, что 95% учебного материала по WPF+ MVVM показано для приложений одного окна. Здесь все понятно и красиво. Но если у меня в приложении может быть 30 различных форм (view), причем они могут вызываться не только из меню, но и из друг друга, то гугление по "wpf mvvm multiple views in one window" приводит к миллиону различных вариантов- от включения в кода в code-behind до использования pages. Причем все это показано максимум на 3-5 различных формах внутри окна. То есть нет устоявшейся best-practice по данному вопросу. Если бы в Winforms я бы сделал эту операцию через 5 строчек Код: vbnet 1. 2. 3. 4. 5. 6.
, то в WPF это далеко не так очевидно. Я совершенно не спорю что мой код велосипедный, однако это единственное на мой взгляд что может заработать. Поэтому и создал пост, чтобы люди посоветовали как они справлялись с данной задачей или имеют какие-либо размышления. Насчет подхода с DataTemplate- если есть 30 различных view, то их нужно все включить изначально? Код: xml 1. 2. 3.
.......... Код: vbnet 1. 2. 3.
? Гуглить всё же лучше примерно так "C# wpf mvvm with multiple window application". Там тебе примерно скажут, что не всегда нужно полностью следовать паттерну MVVM. Иногда можно и из code-behind вызывать дочернее окно. Другое дело, что тогда тебе будет не так легко натянуть понятие модели представления на такой подход - получится, что у тебя окна в code-behind будут оперировать моделями представлений, что выворачивает MVVM наизнанку - ведь code-behind относится к представлению. Я делал нечно подобное, но выглядело это как костыли, которые за собой тянули другие костыли и т. д. А почему вы привязываетесь к окнам? По сути, те же страницы и есть окна, если я правильно понимаю (сам я страницы не юзал ещё), только их не надо закрывать. Суть-то та же - несколько последовательных блоков интерфейса сменяют друг друга, и в предыдущий блок нельзя попасть, пока не закроешь текущий. Ну и из текущего можно открыть следующий. Окна - это всего лишь один из способов реализации такой логики интерфейса. Страницы - другой способ. Дерево - третий способ. Можно придумать свой способ - весь возможный граф открывающихся окон закладывается в граф наследований моделей представлений, а потом это всё мапится на представления через те же DataTemplate. Вам надо только понять суть, которую я выделил жирным. И то, что во всех стандартных гайдах - да, вы правы - есть только способ однооконного приложения со сменой представлений через DataTemplate. Что-то другое придётся искать или придумывать самому. Вот способ реализации настроек в виде дерева (программа Download Master). Посмотрите, может, вам такое подойдёт. В последовательности диалоговых окон каждое окно соответствует ветке дерева. Суть та же, только дерево компактнее и нагляднее. Подробные настройки справа - это конкретные настройки в текущей подкатегории. Т. е. весь ваш граф вызовов диалоговых окон можно отобразить на такое дерево, и, на мой взгляд, это будет лучше, чем 30 различных диалоговых форм, которые, пооткрывав, будут загромождать весь экран, а потом их ещё и закрывать надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 15:31 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей Кvb_subЯ совершенно не спорю что мой код велосипедный, однако это единственное на мой взгляд что может заработать.Не нужно недооценивать "традиционные" подходы, применяемые, например, в WinForms. В WPF они работают не хуже. vb_subесли есть 30 различных view, то их нужно все включить изначально?Если делать по MVVM-ному, то во ViewModel должен жить какой-то идентификатор текущей View. Во View "главной" формы можно вставить DataTrigger-ы или DataTemplateSelector. Если применять MVVM-ный подход, то я бы выбрал первый способ, с триггерами. Как насчёт подхода, что я предложил: составить граф вызовов диалоговых окон, отобразить его на граф вью моделей (например, через включение), для каждой вью модели создать свою вью, отобразить полученный граф вью моделей на дерево и область с контентом справа для текущего выбранного вью? Возможно, для удобства нужно будет создать базовый класс для вью моделей - чтобы на ветки дерева мапились с одинаковыми настройками во вьюхах через DataTemplate. Но это уже детали. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 15:35 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_subАрхитектурно приложение выглядит как в примере ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 15:40 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman Mejtesиногда, когда работаешь с WPF возникает ощущение, что некоторые вещи просто забыли сделать и забили на это основательно. На те же триггеры , которые нельзя определить в самом элементе управления, а можно только в стиле или в шаблоне. Где то читал, что вроде это недоработка и вот вот, это добят, а воз и ныне там :) И будет там. WPF всё - устарел и не нужен больше МС. В фаворе теперь UWP. Ты в UWP смотрел - как там дела с "некоторыми вещами"? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 16:20 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKss, форма более успешной реализации меню приложения, как у Вас на картинке c DownLoad Master- это десятая проблема - можно с помощью графа, что будет компактнее и лаконичнее, можно с помощью кнопок- не столь важно. Причем как правило в приложениях Вы можете перейти из одной формы в другую не только через пункты меню, но и через команду из текущей формы. Как например применительно к Вашей картинке, если нажмем "Ок", то перейдем в какую-либо другую форму, причем иногда нужно передавать в новую форму определенные параметры. Вот с этой организацией действий как раз и не все ясно. Страницы не использовал, потому что никогда с ними не работал- если будет вкрай безысходно, то конечно попробую и их, но там тоже своя кухня. ARKssМожно придумать свой способ - весь возможный граф открывающихся окон закладывается в граф наследований моделей представлений, а потом это всё мапится на представления через те же DataTemplate. Способ самый прямолинейный и максимально рабочий, но например если у меня много форм, для них для всех создались модели-представления и представления, а я воспользовался только одной формой из всех. Во-первых скорее всего загрузка всего графа будет делом не быстрым, и на малом количестве форм это будет незаметно, то при добавлении новых это будет все больше ощушаться на производительности. Во-вторых держать в памяти весь граф окон думаю расточительно по памяти. ARKssТ. е. весь ваш граф вызовов диалоговых окон можно отобразить на такое дерево, и, на мой взгляд, это будет лучше, чем 30 различных диалоговых форм, которые, пооткрывав, будут загромождать весь экран, а потом их ещё и закрывать надо Если Вы имели ввиду MDI- интерфейс, то я не про него имел ввиду. Я подразумевал то, что меняющееся содержимое окна может иметь 30 различных вариантов. А приложение может показывать в текущий момент только 1 форму, при переходе на новую старая скрывается/закрывается ( как в ютубовской демке). В итоге все равно приходится отходить от принципов MVVM и во ViewModel создавать экземпляры View и отображать их в contentcointrol главного окна. Если попытаться реализовать все в слое View, то надо будет включать все варианты окон во View главного окна - если таких различных окон много, то xaml раздуется до террабайта. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 16:34 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_sub, попробуйте как я вам сказал у меня в App.xaml хранятся ссылки на все ресурсные файлы со стилями всех окон. ключем для них будет тип модели вот так: Код: xml 1. 2. 3. 4.
есть класс WindowManager который в методе OpenWindow находит в ресурсах приложения модель MainModel, которая наследована от интерфейса IWindowModel (который определен в пространстве имён WindowManager) и который позволяет управлять окном из модели представления (обрабатывать события закрытия окна и блокировать их, сворачивания, разварачивания и т.д.) создает объект Window, задает ему найденный стиль, если стиль не найден, окно не открывается, а выдается соотвествующий Exception. затем WindowManager обёртывает окно в отдельный Wrapper который поддерживает иерархию окон, для каскадного закрытия и т.д. Какие плюсы: мы можем открывтаь и закрыывать окна прямо в ViewModel, при этом ViewModel ни чего не знает ни об окнах, ни о стилях и т.д. в ресурсах мы можем быстро найти какое окно (стиль окна) предназначен для какой модели представления, так как мы связываем их по типу. Мы можем легко из любой точки программы закрыть окно для нужно нам модели просто передав в процедуру закрытия только ссылку на модель. с помощью WM мы контролируем весь геморой с окнами Какие минусы: - не все свойства можно определить для окна через стиль, но всегда можно это решить опять же через WM - для 1 модели представления мы можем задать только 1 стиль, так как нельзя создать 2 стиля с 1 типом они либо будут перекрывать друг друга либо конфликтовать, но это опять же можно решить через WM (перегрузить метод открытия с указанием ключа стиля) - для того, чтоб открыть окно которое будет диалоговым, блокировать parent\owner нужно явно указать либо ссылку на экземляр VM, что может быть не всегда удобно. Но в WM есть свойства MainWindowModel и CurrentWindowModel можно открывая окна привязаться к ним. точно так же я обычно делаю и с Page'ами, каждая модель Page'а наследуется от какого то базового класса или интерфейса аля IMyPage, затем для каждой странички я создаю свой <DataTemplate x:Key="{x:Type MyPage1}"/> В качестве контейнера работает ContentPresenter или ContentControl, в котором определен DataTemplateSelector, который в свою очередь ищет у себя в коллекции шаблоны, либо в ресурсах приложения и т.д. Находит и задает соотвествующий шаблон. На коленке такое написать не получится, но думаю вы часа за 3-4 осилите :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 17:46 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_subПричем как правило в приложениях Вы можете перейти из одной формы в другую не только через пункты меню, но и через команду из текущей формы. Как например применительно к Вашей картинке, если нажмем "Ок", то перейдем в какую-либо другую форму, причем иногда нужно передавать в новую форму определенные параметры. Я не понял этого. У вас сразу много форм открыто и вы между ними параметры передаёте, или как? Зачем вообще между формами чего-то передавать? У вас должен быть слой (я назвал это моделью представления), где вы храните все параметры. И формы или представления - это только для отображения этих параметров. Если вы сохранили какие-то параметры в какой-то форме, значит, вы сохранили их на этом специальном слое. Если хотите, можете организовать этот слой так, чтобы другие формы знали о сохранённых параметрах - значит, отдельные элементы этого слоя должны знать о других элементах, где эти параметры хранятся. Как это организовать - наследованием, включением, глобальными сервисами с подписками - это другое дело. Главное, что вы сначала моделируете свой интерфейс в специальном слое, прорабатываете его логику на языке программирования, а только потом на формы его накидываете. После проработки логики интерфейса в классах, вы можете на эти классы нацепить любой вид этого интерфейса - любые представления, любую организацию форм, в наших терминах. Я ещё раз говорю - кто вам сказал, что у вас именно ФОРМЫ? Может, у вас какой-то шаблон, которым вы мыслите, и кроме кучи вызываемых друг из друга форм вам трудно представить что-то другое? Попробуйте продумать сначала свой интерфейс логически, без связи с кучей форм. И тогда, возможно, вы придумаете, что есть организация UI получше (если она действительно есть). Ну и, наконец, если вам как-то удавалось сделать кучу форм на Windows Forms, то абсолютно точно такое же поведение нет проблем получить и на WPF. WPF позволяет один в один писать так же, как на Win Forms. Т. е. если вы не хотите заморачиваться с MVVM, можете просто использовать WPF как WinForms. Тогда от WPF можно взять только компоновочную схему, стили, анимации и прочую подобную гибкость в оформлении, которой нет в WinForms, при этом вам совершенно не обязательно использовать привязки, шаблоны данных, поведения, команды и прочее. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 17:52 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKss, ну в привязках источником можно легко указать форму, как минимум 3 разными способами, если вся логика и свойства в codebehind классе формы ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 17:57 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_subВо-вторых держать в памяти весь граф окон думаю расточительно по памяти. Посмотрите на картинки - там сразу все окна-представления загружены? Справа отображается только текущий выбранный узел - ваша форма. А вот когда у вас куча форм открыто - тогда да, сразу куча представлений загружено. Так что мой вариант даже менее затратным по ресурсам будет, получается. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 18:06 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_subЯ подразумевал то, что меняющееся содержимое окна может иметь 30 различных вариантов. А приложение может показывать в текущий момент только 1 форму, при переходе на новую старая скрывается/закрывается ( как в ютубовской демке). В итоге все равно приходится отходить от принципов MVVM и во ViewModel создавать экземпляры View и отображать их в contentcointrol главного окна. Если попытаться реализовать все в слое View, то надо будет включать все варианты окон во View главного окна - если таких различных окон много, то xaml раздуется до террабайта. Если выделенное - то, что вам нужно, тогда не вижу проблем. Я предложил как раз такой вариант. И MVVM'у это не мешает. Во вью модел не надо создавать экземпляры вью. Во вью модел вы изменяете свойство, которое отображается на текущую область справа, и вью главного окна сама подбирает нужно вью для области справа по Data Template. Это всё описано в паттерне MVVM - вы кликаете на кнопку во вью; выполняется команда во вью модел, которая меняет нужное свойство; отображение этого свойства во вью также изменяется. Будет ли это свойство банальным элементарным значением (число, строка и т. п.), которое отображатеся в каком-нибудь текстбоксе, или это будет целый сложный объект, для которого нужно своё под-представление - это не важно. Важно, что делаться это будет так, как написано, если придерживаться нескольких правил шаблона MVVM. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 18:14 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman MejtesARKss, ну в привязках источником можно легко указать форму, как минимум 3 разными способами, если вся логика и свойства в codebehind классе формы Если вся логика и свойства в коде поддержки, то это уже не MVVM, а что-то своё. Соответственно, и дальнейшее всё лежит уже на ваших плечах и вашей ответственности - заставить это своё как-то работать. Если вы в силах и вам WPF'овский MVVM поперёк горла стоит - пожалуйста. А куча открываемых последовательно модальных форм действительно плохо ложится на классический MVVM. Надо всякие сервисы глобальные, подписки на эти сервисы городить и всякое такое. Лично я для простого модального "ОК, Cancel" использую код поддержки - т. е. отступаю от MVVM, ибо, действительно, ради простой такой вещи городить сервис это слишком муторно. Но если у вас не один такой простой тип окон, то придётся как-то заморочиться. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 18:18 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssRoman Mejtes то придётся как-то заморочиться. Например, как Roman Mejtes предложил. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2016, 18:23 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKss, предложенный мною вариант не нарушает принципов паттерна MVVM, в чем вы видите проблему? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2016, 01:08 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman MejtesARKss, предложенный мною вариант не нарушает принципов паттерна MVVM, в чем вы видите проблему? Я последнее добавил из вежливости, только чтобы не выглядело, что я тут тему засираю своим видением. Так-то я даже толком не разбирался, что вы предложили - какой-то сервис, менеджеры. Просто, на мой взгляд, в MVVM никак не оговариваются такие глобальные сервисные классы. MVVM вообще не про глобальные объекты, и глобальные сервисы добавляются к нему как костыльная нашлёпка сбоку, чтобы идиллия MVVM была применима и на практике, а не только в простейших тестовых примерах. Или я ошибаюсь? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2016, 05:13 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman MejtesАлексей К, кстати, не так давно столкнулся с такой проблем :) примерно как вы описали. Когда используешь связку ViewModel + DataTemplate (которую я люблю), при "переоткрытии" окна с этой связкой или при переходе на другую страницу приложения и возрате на старую состояния определенный только на уровне View будут сброшены, так как визуальное дерево будет по шаблону отстроено заново. То, есть могут слететь выделения в ListBox'а, если они не синхронизированны с представлением коллекции и так далее. Так, что гонят на автора зря, не даром ContentPresenter представляет возможность отображения содержимого на основе шаблона или на основе содержиомого из готовых элементов.Да. Вполне себе жизненная ситуация. Я с таким тоже сталкивался. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2016, 04:01 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKsscode-behind относится к представлениюЭто глобальное заблуждение MVVM-паттерноидеологов. Если code-behind рассматривать как разновидность view model, то всё встаёт на свои места. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2016, 04:03 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей КARKsscode-behind относится к представлениюЭто глобальное заблуждение MVVM-паттерноидеологов. Если code-behind рассматривать как разновидность view model, то всё встаёт на свои места. А при этом ты ещё и нормальную вью модель добавляешь, или только в коде поддержки её оставляешь? А то получается, что у тебя либо вью модель на два несвязанных файла-класса разбита, либо вообще две вью модели. Оно надо, так множить сущности? авторкстати, не так давно столкнулся с такой проблем :) примерно как вы описали. Когда используешь связку ViewModel + DataTemplate (которую я люблю), при "переоткрытии" окна с этой связкой или при переходе на другую страницу приложения и возрате на старую состояния определенный только на уровне View будут сброшены, так как визуальное дерево будет по шаблону отстроено заново. То, есть могут слететь выделения в ListBox'а, если они не синхронизированны с представлением коллекции и так далее. А нельзя сразу при выделении чего-то в листбоксах и прочих контролах синхронизировать это со вью моделью? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2016, 06:45 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssОно надо, так множить сущности?Да, зачем множить сущности, если уже дан code-behind, который во многих случаях удобно использовать в качестве view model, если требуется применить конструирование типа view first. Только не надо относиться к этому как к единственному подходу. Относись к этому как к одному из возможных. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2016, 07:04 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssавторкстати, не так давно столкнулся с такой проблем :) примерно как вы описали. Когда используешь связку ViewModel + DataTemplate (которую я люблю), при "переоткрытии" окна с этой связкой или при переходе на другую страницу приложения и возрате на старую состояния определенный только на уровне View будут сброшены, так как визуальное дерево будет по шаблону отстроено заново. То, есть могут слететь выделения в ListBox'а, если они не синхронизированны с представлением коллекции и так далее. А нельзя сразу при выделении чего-то в листбоксах и прочих контролах синхронизировать это со вью моделью?Ты же понимаешь, что WPF предоставляет множество способов решения данной задачи, и все они правильные. Вопрос в том, какой из них удобнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2016, 07:08 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
мне кажется у многих программеров использующих шаблон MVVM очень часто возникает непонимание того, что должно быть во View, а что в ViewModel. Особенно когда речь заходит о сложных компонентных элементах управления, которые имеют очень слабую абстракцию. Именно тогда возникает непонимание, почему одни классы оказываются во View, а другие во ViewModel или если между 2умя слоями лежит тонкая грань. Взять к примеру ICollectionView. Между View и ViewModel могут быть определенные соглашения и они сущетсвуют INotifyPropertyChanged, IEditableCollectionView, ICommand. Ни какого ограничения на codebehind в MVVM нет, до тех пор пока этот codebehind класс не начинает оперировать классами модели представления. Самый верный путь во организации сложного взаимодействия это использовать интерфейсы и контракты. Состояния View объектов определять простыми структурами с помощью свойствах зависимости. Во View экземляры объектов должны быть преимущественно упакованными в object и т.д. На счет "кому как удобно", я думаю надо придерживаться каких то соглашений в команде, даже если команда из 1 человека, а не работать как кому удобно =) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2016, 09:38 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей КARKssОно надо, так множить сущности?Да, зачем множить сущности, если уже дан code-behind, который во многих случаях удобно использовать в качестве view model, если требуется применить конструирование типа view first. Только не надо относиться к этому как к единственному подходу. Относись к этому как к одному из возможных. Ну да, если у тебя на одну вью модель строго одна вью (т. е. это точно не универсальное приложение со своей разметкой под разные типы девайсов), то такой костыль пойдёт. Однако, ты такой сидишь, костыли гонишь на потоке, объясняя это то "тут можно и так обойтись", то "здесь плюём на классику, потому что типа слишком мудрёно и ваще лень" и прочими отговорками, а потом приходит другой чел или команда и охреневают от такой самодеятельности. Пойди пойми, что ты имел ввиду там и тут, городя свои велосипеды. Где унификация подходов? Если каждый Вася будет свои костыльные паттерны городить, чем всё это закончится? Джаваскриптом хатемээлевого замеса, прости господи? Ладно, для дома, для семьи можешь извращаться как хочешь, но у себя на работе ты, надесь, не внедряешь такие практики на всю команду и повсеместно? Roman MejtesВо View экземляры объектов должны быть преимущественно упакованными в object и т.д. Попахивает джаваскриптом и бесовской нетипизацией... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2016, 18:03 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman Mejtes, авторесть класс WindowManager который в методе OpenWindow находит в ресурсах приложения модель MainModel, которая наследована от интерфейса IWindowModel Вы пользовались этим ресурсом для создания WindowManager http://www.nichesoftware.co.nz/2015/08/23/wpf-window-manager.html ? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2016, 20:51 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
vb_sub, не, я шел своей дорогой, похоже, но вижу в 1 раз :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.12.2016, 21:48 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssАлексей Кпропущено... Да, зачем множить сущности, если уже дан code-behind, который во многих случаях удобно использовать в качестве view model, если требуется применить конструирование типа view first. Только не надо относиться к этому как к единственному подходу. Относись к этому как к одному из возможных. Ну да, если у тебя на одну вью модель строго одна вью (т. е. это точно не универсальное приложение со своей разметкой под разные типы девайсов), то такой костыль пойдёт. Однако, ты такой сидишь, костыли гонишь на потоке, объясняя это то "тут можно и так обойтись", то "здесь плюём на классику, потому что типа слишком мудрёно и ваще лень" и прочими отговорками, а потом приходит другой чел или команда и охреневают от такой самодеятельности. Пойди пойми, что ты имел ввиду там и тут, городя свои велосипеды. Где унификация подходов? Если каждый Вася будет свои костыльные паттерны городить, чем всё это закончится? Джаваскриптом хатемээлевого замеса, прости господи? Ладно, для дома, для семьи можешь извращаться как хочешь, но у себя на работе ты, надесь, не внедряешь такие практики на всю команду и повсеместно? Roman MejtesВо View экземляры объектов должны быть преимущественно упакованными в object и т.д. Попахивает джаваскриптом и бесовской нетипизацией...Создаётся впечатление, что ты знаешь всё лучше всех. Продолжай, очень интересно! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2016, 04:30 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей КСоздаётся впечатление, что ты знаешь всё лучше всех. Продолжай, очень интересно! У меня просто есть своё мнение. Которое я иногда меняю, между прочим. У тебя не так? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2016, 05:05 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
ARKssУ меня просто есть своё мнение.Не буду тебя разочаровывать. Тема себя исчерпала. С наступающим! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2016, 05:37 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Алексей К, всё это хорошо - новые годы всякие и т. д. Только проблема ТСа, как я понял, так и не решилась? Или мы ему накидали столько, что ему трудно выбрать? Тут говорили, что вью состояние не запоминает. Ну так коде-бихайнд связан со вью, и когда оно уничтожается (переходим на другую страницу), то и коде-бихайнд его уничтожается. И когда ты вью модель хранишь в коде-бихайнд, то она тоже уничтожается. Естественно, что у тебя данные не будут сохраняться, если ты их уничтожаешь. А вот когда сохраняешь их во вью модели нормальной, отдельной, которая ещё и не сама по себе, а во вью модели главного окна, тогда при смене представлений данные сохраняются (конечно, если ты это обеспечил через всякие INotifyPropertyChanged и т. п.), и загрузка снова этого же представления проихсодит с обновлёнными (т. е. сохранёнными) данными. Коде-бихайнд планировался использоваться как поддержка для контролов вью - всякие сложные анимации (по каким-то сложным таймерам, например) и прочие манипуляции, которые нельзя сделать чисто разметкой. Ещё как костыль для вызова дочернего модального окна - ладно уж. Но не для полноценноо переноса всех данных в этот коде-бихайнд. В чистом MVVM "без выкрутасов" коде-бихайнд вообще чистый (пустой конструктор и всё) и его даже можно удалить из проекта. Т. е. я согласен с тобой, что можно немного отступить от канона, где это действительно требуется из-за недоработки этого канона, но оправдывать абсолютную наглость и распущенность причиной "пусть расцветают все цветы" не нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2016, 06:50 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
[spoiler] ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2016, 06:53 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Пока что пробую предложенные здесь варианты. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2016, 10:31 |
|
Навигация между UserControl
|
|||
---|---|---|---|
#18+
Roman Mejtes, Roman Mejtesточно так же я обычно делаю и с Page'ами, каждая модель Page'а наследуется от какого то базового класса или интерфейса аля IMyPage, затем для каждой странички я создаю свой <DataTemplate x:Key="{x:Type MyPage1}"/> В качестве контейнера работает ContentPresenter или ContentControl, в котором определен DataTemplateSelector, который в свою очередь ищет у себя в коллекции шаблоны, либо в ресурсах приложения и т.д. Находит и задает соотвествующий шаблон. Главное окно-контейнер: Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29.
DataTemplateSelector Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.
View отображаются, только без привязки к ViewModel. Поначалу думал, что связка идет через Код: xml 1. 2. 3.
но это не так. Как Вы связываете View c ViewModel? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2016, 15:56 |
|
|
start [/forum/topic.php?all=1&fid=21&tid=1440579]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
171ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
81ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 310ms |
0 / 0 |