2012-02-21 7 views
0

У меня есть приложение, использующее MVVM. Я пытаюсь перехватить нажатия клавиш на пульте дистанционного управления MCE для воспроизведения, паузы, остановки и т. Д. В настоящее время я использую привязки команд с помощью метода в коде, который выполняет соответствующее действие на медиа-элементе как таковойЕсть ли лучший способ, чем обработка CommandBindings в коде?

<Window.CommandBindings> 
    <CommandBinding Command="MediaCommands.Play" Executed="PlayMediaElement"/> 
    <CommandBinding Command="MediaCommands.Stop" Executed="StopMediaElement"/> 
</Window.CommandBindings> 

Прежде чем пытаться включить функциональность пульта дистанционного управления, у меня было около 10 моделей-представлений/представлений, в которых ничего не осталось. Мне интересно, есть ли лучший способ сделать это, поэтому я сохраняю шаблон MVVM или это вполне приемлемо/предпочтительнее реализовать таким образом.

EDIT - Я переместил командные привязки из UserControl внутри представления в свой MainWindow.xaml и разместил методы в MainWindow.xaml.cs. У MainWindow нет отношения view/viewmodel, просто элемент управления содержимым с привязкой к нему ViewModel. В моем коде за методами я использую посредник для отправки сообщений (Play, Pause, Stop и т. Д.) В мою среду mediaplayerview, которая, в свою очередь, взаимодействует с соответствующим видом. Это хорошая идея или есть лучший способ?

+0

[Как найти источник ошибки привязки?] (Http://stackoverflow.com/a/8480651/485076) – sll

ответ

1

Я думаю, что Джош Смит создал огромную путаницу в своей статье в 2009 году, когда он сделал вывод, что его файлы CS, хранящиеся в коде, остались в основном пустыми. MVVM не о том, чтобы не иметь кода. Речь идет о разделении проблем. Если есть какое-либо практическое правило, за которым следует следовать, нужно сделать представление ViewModel агностиком (т. Е. Не ссылаться на ViewModel на представление. Подумайте о второй реализации тестового исполнения «View» для вашего ViewModel).

Эта путаница «без кода позади» вызвала очень нечетные структуры, чтобы работать вокруг проблемы, которой не должно было существовать.

Наличие кода в MainWindow.xaml.cs является вполне разумным решением, если у вас нет логики, но просто переадресуйте вызов на соответствующий метод в Model View. Если бы это был мой код, я бы создал пользовательские команды (a la DelegateCommand из той же статьи), которые напрямую привязаны к командам в ViewModel, но ваш дизайн также на 100% закончен.

+0

Фактически нет, это ограничение фондового WPF. Фондовый WPF не может использовать разумные методы вызова, определенные на представлении или контроллере. – TomTom

+1

Не знаете Почему это было отмечено? Я пошел с решением, основанным на последнем абзаце. Я создал пользовательские маршрутизированные команды, которые пузырятся до mainwindow (у которых нет представления), но манипулируют режимами просмотра. – Oli

0

Перейдите на сайт Codeplex.com и найдите Caliburn (или лучше Caliburn Micro). Он расширяет WPF, чтобы фактически разрешить вызов методов с произвольными параметрами, вытащенными из других объектов, и метод, находящийся в модели/контроллере представления, без использования метода «крюка» в коде, стоящем за тем, как только перемещается вызов.

Расширения могут делать замечательный thignsl ike вытягивать значение текстового поля и передавать его как параметр методу, а затем реагировать на возвращаемое значение - как и в случае с представлением.

Вы используете ограничение «запаса» wpf, которое просто может указывать только на обработчики методов в коде без каких-либо параметров. Альтернанты существуют, даже с Microsoft.

Смежные вопросы