Лучшая практика для вызова View из ViewModel в WPF

Я ищу небольшой пример проекта wpf, в котором содержится наилучшая практика для навигации между представлениями. Возможно, с инфраструктурой MVVM Light и NavigationService или ServiceLocator. Вместо вызова View из ViewModel, как вы это делаете? Как ваш подход? У вас есть пример проекта?

Ответ 1

Я предпочитаю иметь главное окно с контролем содержимого. За этим стоит модель представления с состоянием состояния приложения, основанное на общем перечислении.

Перечисление предназначено для представления текущего состояния, но считайте, что каждый из них должен отображаться, если это проще.

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

Этот подход требует, чтобы вы управляли селектором шаблонов с свойствами шаблона для каждого значения перечисления или представления, которое вы хотите быть основным контентом. Но шаблон должен включать только экземпляр вашего представления, поэтому минимальный XAML.

В фоновом режиме я использую свет MVVM для создания источника данных локатора Viewmodel, что делает мои представления очень легкими для создания экземпляров. Они также используют одномодовую модель просмотра, поэтому управление состоянием выполняется между режимами использования. Затем я также использую структуру обмена сообщениями для отправки сообщений в модель моего главного окна, сообщающую, какое состояние я сейчас хочу. Это означает, что любая модель просмотра может отправлять сообщение для переключения в другое состояние, не зная, какой вид будет, но в конечном итоге модель основного окна управляет этим переходом.

Извинения за отсутствие примеров кода здесь, это контур того, что я сделал несколько раз, но у меня нет чистого образца для публикации.

Это, мы надеемся, достаточно, чтобы объяснить мой подход, но не стесняйтесь комментировать, если это не имеет смысла или подходит тому, что вы пытаетесь сделать.

Для диалогов... Обычно у меня есть диалоговые окна по умолчанию, которые я использую повторно, но можно использовать тот же принцип. Вместо того, чтобы управлять основным окном и виртуальной машиной, у вас есть вторичный для диалогов, который работает одинаково, но делает себя видимым по запросу и закрывается после завершения. Снова mvvm light messenger - ваш друг здесь.

Ваше сообщение содержит диалоговое "состояние", которое контролирует представленное представление.

Это будет работать только в том случае, если в вашем дизайне будет доступно только по одному диалогу за раз.

Наконец, для вкладок...

Я бы посмотрел на наличие наблюдаемой коллекции перечисления состояний в модели основного вида. Затем создайте вкладки, привязавшись к этому. Не то, что я сделал, но это то, где я начинал. -

Ответ 2

Я предпочитаю первый подход ViewModel. Это означает, что служба навигации принимает viewmodel как параметр, а затем, основываясь на соглашении об именах, создается экземпляр представления и загружается в фрейм.

navigationService.Navigate<SomePageViewModel>()

Это имеет несколько преимуществ перед навигацией на основе URI, которая представляет собой первый подход:

  • Лучшая тестируемость
  • возможность ввода зависимостей в представление
  • Самое главное: Лучшая переносимость. Если вы переименуете или переместите свои страницы, это не будет компилироваться, пока вы не исправите его, в отличие от URI. Uri будет вызывать ошибку во время выполнения

К несчастью, я не могу дать вам свой примерный проект прямо сейчас, но довольно легко реализовать свой собственный