|
Навигация между 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?fid=21&gotonew=1&tid=1440579]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
170ms |
get topic data: |
11ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
others: | 238ms |
total: | 523ms |
0 / 0 |