WPF / MVVM - держать ViewModels в компоненте приложения или отдельно? - PullRequest
2 голосов
/ 15 января 2011

У меня есть приложение WPF, в котором я использую шаблон MVVM.

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

Я начал разделять виртуальные машины на отдельный компонент / сборку, частично потому, что я вижу их как часть для тестирования модулей, частично потому, что представления должны полагаться на ВМ, а не наоборот.Но когда мне нужно вызвать окно, оно не известно виртуальной машине.

Все находки, которые я обнаружил, помещают виртуальную машину в компонент WPF / App, что устраняет проблему.

В этой статье рекомендуется хранить их в отдельных слоях: http://waf.codeplex.com/wikipage?title=Architecture%20-%20Get%20The%20Big%20Picture&referringTitle=Home

На мой взгляд, у меня есть следующие варианты:

  1. Переместить виртуальные машины в сборку WPF / App, чтобыразрешить виртуальным машинам получать прямой доступ к окнам.

  2. Размещать интерфейсы представлений в сборке VM, реализовывать представления в сборке WPF / App и регистрировать соединение через IOC или альтернативные способы.

  3. Подать «запрос» от ВМ на какой-нибудь механизм / шину, которая направляет запрос (но какой механизм!? Например, что-то в Prism?!)

Какая рекомендация?

Спасибо за любые комментарии,

Андерс, Дания

Ответы [ 2 ]

2 голосов
/ 15 января 2011

Не выбирайте вариант 1. Вы будете добавлять нежелательную зависимость от виртуальной машины к V.

Опции 2 и 3 действительны и используются. Выбор между ними иногда является делом вкуса. Я думаю, что IOC позволяет / разрешает mocking лучше, тогда как шину сообщений отлично работает для небольших приложений.

0 голосов
/ 17 января 2011

Храните ваши ViewModels в отдельной сборке от Views.

Если вы посмотрите на Cinch и MEFedMVVM , вы увидите очень мощные механизмы для соединения видов и моделей представления с использованием MEF .Их раздельное хранение позволяет запускать приложение без головы (без пользовательского интерфейса), что отлично подходит для тестирования и демонстрации API.

...