Сабж. Хочется управлять своим MediaElement расположенным в View с ViewModel. Хочется использовать такие методы как Play, Stop, Pause. Ищу правильное решения. В инете нашёл решения, в котором MediaElement держат непосредственно в ViewModel, но это как-то не по фен шую. 

Правильно, что вы говорите что это не правильно 
Ну тут абстракция не должна быть более особенной, чем от, например, диалогового окна. Я для абстракции задач относящихся непосредственно к представлению использую интерфейсы, зарегестрированные в каком нить сервис-провайдере или контейнере, не важно. Также использую мессенджеры.
Ну а если требуется управлять вашим медиа только из одной модели представления, то вы можете обойтись делеагатами, передаваемыми из представления в модель, либо интерфесом каким-нить, который также передается в модель самим представлением, или событиями в модели на которые подвешивается представление, или биндинги в конце концов... Вариантов море, но однозначно, не следует размещать именно MediaElement на стороне модели представления. Другое дело, если механизм воспроизведения звука не будет UI-зависимым (DirectX например). Для такого, можно и модель отдельную сделать и уже к ней привязать представление. В общем смотрите как вам надо. По любому из перечисленных вариантов могу продолжить писать, если вам интересно.

Ну я создал на стороне представления свойство зависимости и через него уже управляю, но этот вариант тоже не особо хорош, потому что  code-behavior не пуст...

А это смотря на сколько он не пуст. Если в его задачи входит только управление или малая часть связки на стороне только представления, без логики самого приложения, то это ничего страшного. Например, вы можете спокойно раместить обработчик клика кнопки (вместе или без заданной команды) если при клике меняется цвет фона например. Не состояние модели, от которого зависит цвет фона, а вот просто, чисто дизайнерский наворот. Либо вы можете спокойно размещать код, который мониторит или задает значения свойств модели лежащей в контексте данных (опять таки если это не связано с логикой приложения). Любо подцепиться на событие в модели. Общий смысл таков, что в код-бехинде не должен располагаться код, от которого зависит работа самого приложения. Не рекомендуется, например, связывание двух и более моделей в код-бехинде (да и через XAML тоже), так как что и с чем связано относится к логике. Идеально, когда одно представление знает только о той модели, для которого оно разработано. Это вполне достижимо (мне по крайней мере это удается). Я могу привести пример того, что вам необходимо, только скажите мне, какой способ абстракции из перечисленных мной в предыдущем посте вы предпочитаете.

Добавлено через 8 минут и 56 секунд
Код-бехинд, не обязан быть пустым. В шаблоне оговаривается, что он будет минимальным и в большинстве случаев вообще пустым, так как логика переносится в модель представления. Любая интерактивность с пользователем - это представление, а принятие решений по этому поводу - это модель рпедставления. Код-бехинд может содержать даже код связывания между элементами управления, если биндингом это недостижимо или биндинг получается нечитабельным.

-Mikle-, моё понимание паттерна mvvm было не совсем правильным, я почему то считал что view не должно иметь никакого кода, имеющего какого либо отношения к логике приложения, но похоже это совсем так... Оно и не должно его иметь (логику уровня приложения), однако оно должно иметь код, с помощью которого viewmodel может иметь контроль над view... Теперь я так понимаю данный паттерн... В принцепе то что вы описали в посте выше   



Было бы очень хорошо если бы вы привили пример с использованием мессаджеров, так как о данных объектах я ничего не знаю

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


Это не стандартные классы и поведение. В составе наших проектов мы используем самописный мессенджер. Он довольно тривиален и суть его такова, что любой объект в домене приложения может зарегистрироваться для получения сообщений определенного типа. Далее, любой объект может также отправлять сообщение какого-то типа и все зарегистрировавшиеся получатели его получают. Привести код этого класса я не могу, так как права на исходники принадлежат компании в которой я работаю, но я поискал щас в инете и нашел похожую реализацию этой идеи. Правда как я понял, та реализация куда более тривиальна, чем наша, но подойдет для простых задач.
Через мессенджер можно сделать так, чтобы view регистрировалась на получение сообщений своего типа. При получении сообщений, она выполняет соответствующие действия. Так как мессенджер является синглтон-объектом, то он доступен из любого места приложения и любая модель представления (не зависимо от того для чего она создана) в таком варианте может отправлять сообщения на воспроизведение звука или видео. Я приведу код мессенджера описывающий только идею без детальной реализации. Не берите за основу сигнатуры его методов, так как на самом деле нужно о многом позаботиться прежде, чем запоминать обработчик сообщения.



А вот примерная идея реализации на основе мессенджера:
1) Классы сообщений проигрывателя


2) Класс проигрывателя. Я сделал его пустым, так как ориентировался только на звук, который не имеет отображения. Нет никаких проблем сделать его таким, каким вы себе его представляете.



Теперь, если у вас в любом месте UI где-то расположен MediaPlayer (его не видно и он не будет мешать), то вы можете проигрывать сколько угодно мелодий одновременно.


Как видите, тут все очень просто. В этом примере даже близко нет ни упоминания ни использования MVVM. Всю задачу абстракции решает тут мессенджер. Код который отправляет сообщения, ничего не знает о проигрывателе. Проигрыватель вообще может не существовать и вызывающий код будет продолжать работать (просто беззвучно). А если отправляющей стороне необходимо знать проигрывается звук или нет, то я пердусмотрел в примере сообщения свойство Handled. MediaPlayer выставляет его в true, если она отработала сообщение. Также, вы можете в любой момент добавить новые поддерживаемые сообщения или заменить их обработчик например на DirectX. Абстрагировать через мессенджер можно даже несколько viewmodel между собой. В общем, думаю эта идея тут достаточно развернута, а мне пора идти гулять со своими детишками