Надлежащий способ отобразить всплывающие окна с помощью WPF M-V-VM шаблон

Не помещайте код UI в VM, что правые дела много головных болей в будущем.

У Вас обычно есть два случая, когда Вы хотите вытолкать окно или диалог. Или Вы делаете его из-за экономической модели, например, деталь просматривает при двойном щелчке по списку, или это - полностью UI, базирующийся, например, сование окна настроек. В первом случае лучше использовать событие в VM, в более позднем случае я просто использую обработчик событий. Хорошее эмпирическое правило, если Вам не нужны никакие (значительные) переменные VM для выполнения действия затем, необходимо просто использовать обработчик событий.

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

Проверьте Оникс . Это библиотека MV-VM (полное раскрытие: я автор), основанная на использовании сервисов и шаблонов Service Locator или Dependency Injection. Есть сервисы для MessageBox и общие диалоги, и довольно легко добавить свои собственные сервисы.

Несколько других опций, не упомянутых другими:

Релейная команда

VM выполняет команду, что мне нравится называть "релейную команду". Это - команда, обработанная кем-то еще, и VM не заботится кто. Выполнение команды действительно только повышает Executed событие. Ваше представление подписалось бы на это событие и отобразило бы содержание в новом Window (содержание было бы передано как параметр команды).

Обратите внимание, что релейная команда не является направленной командой. Это не ищет обработчик в своей логике выполнения. Это просто генерирует событие.

Сервис

Если существует много экземпляров, где необходимо показать что-то в окне, запишите сервис UI, который заботится о нем. VMs затем зависят от этого сервиса (который можно легко дразнить) отобразить содержание в окнах.

Я использую события, которые обрабатываются представлением. Мне не нравится он 100%, но это включает автоматизированное тестирование.

Я сказал бы, что лучший способ пойти, определяют Popup в XAML и затем используют a DataTrigger связанный с некоторым условием в Вашем ViewModel скрыть или отобразить его. Затем, если Вы заботитесь об обработке возвращаемого значения от Popup, имейте EventTrigger в Popup управляйте ViewModel свойства для отражения того изменения.

Существует большой разговор вокруг этого вида области, которая я думаю, то, потому что люди привыкли программировать в мире WinForms. Я должен все же найти решение, где мне был нужен любой код в представлении кроме выбрать исходные данные или установить DataContexts

Создайте интерфейс для своего всплывающего диалогового окна, даже если Вы планируете использовать messagebox.

У основания представления Вашего представления иерархия имеют метод для предъявителя для регистрации класса или формы, реализовывая всплывающее окно.

Имейте свой вызов представлений зарегистрированное всплывающее окно.

Have a ViewModel for popup and View as user control. Depending on the complexity of the popup it can be either universal VM or concrete VM for the business case. When trying to display it from parent's VM, create a "host" class for the popups's VM (inherited from Window or Popup), show it and assign the VM to it. Host should have responsibility of locating proper view (f.e. through DataTemplate)

In this case your popup's VM is still testable and the minimal level of coupling with WPF for parent's VM is acceptable, IMO.

Я действительно соглашаюсь с Carlos, что использование подписки события в представлении не является хорошим выбором. Насколько я понимаю MVVM, он ведет для устранения любого кода позади из представления, и мне действительно нравится он :). Один из proprs MVVM является способностью к модульному тесту это. Но я все еще полагаю, что модель представления может быть протестирована, даже если она открывает окна. Все, в чем мы нуждаемся, должно только использовать Окно с инициализированным Содержанием с необходимой моделью представления. Я думаю, что могло быть 2 возможных ситуации, когда VM должен открыть новое диалоговое окно: или чтобы показать окно опций/настроек или показать окно, которое зависит от бизнес-логики. В первом случае новый код окна является единственным кодом команды (команда для кнопки/пункта меню 'Settings' или 'Options'). Во втором случае у нас есть некоторая логика принятия решений, которая открывает окно. Но в любом случае мы можем переместить код, который открывает новое окно в отдельный метод / класс и при тестировании нашего VM только для насмешки этого метода/класса. Еще больше этим отдельным классом может быть некоторый добрый универсальный WindowsController, который будет отслеживать все окна в приложении. Но тем не менее мы можем сказать, что модель представления открывает всплывающее окно с помощью помощника, WindowsController и представление не знают ничто больше о других окнах. Вся бизнес-логика остается инкапсулированной в модель представления и модель.