Newsgroup: it.comp.dotnet
Titolo: MediaElement in uno scenario MVVM

Ciao a tutti,
 
sto cercando di usare un componente MediaElement in uno scenario MVVM. 
Il componente MediaElement (per quello che mi serve) espone i seguenti 
metodi/property:
 
- .Source: property di tipo Uri che indica il file da suonare
- .Play()/Pause()/Stop(): metodi dal significato ovvio. :-)
 
ho un viewmodel che per ora contiene solo la property MediaSource (di 
tipo Uri) a cui viene bindata la property Source del componente 
MediaElement nello XAML:
 
//ViewModel
class MediaPlayerViewModel : INotifyPropertyChanged {
	//...
	public Uri MediaSource { get; set; }
}
 
<!-- NELLO XAML -->
<MediaElement x:Name="mediaElement" Source="{Binding MediaSource}"  .../>
 
La domanda è: come faccio a "controllare" il media element dal view 
model? E' possibile? E' giusto (in un'ottica 100% MVVM)? Oppure sono 
completamente fuori strada?
 
Grazie,
Giulio
 
-- 
 

 fuori strada?
 
dovrei chiedere a Corrado Cavalli e Giorgio che ci hanno lavorato 
parecchio per un progetto aziendale ma a naso direi che non puoi se non 
facendoti un bel set di attached properties (o behaviors) che facciano 
il lavoro sporco, e a quel punto saresti 100% m-v-vm
 
.m
 
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com/profile/mauro
 
blog @ 
http://milestone.topics.it
 
whynot [ at ] topics [ dot ] it
 
 


 
I metodi di un controllo sono il punto debole di MVVM.
Per punto debole intendo ciò per cui scrivi più codice di quanto 
sarebbe lecito attendersi.
 
A seconda dello scenario puoi risolvere in modi diversi.
Sistema 1:
Crei un custom control (non user control) che è un mero wrapper ed 
esponi proprietà sul cui trigger chiami i rispettivi metodi.
Per esempio una proprietà status che è di un tipo enum con play, pause, 
stop, etc.
 
Se vuoi che sia bindabile dovrai farla diventare una DP e usare la 
notifica per chiamare i metodi.
Questo è un po' più rognoso perché lo stato del controllo non è a posto 
fino a che non viene chiamata applytemplate.
 
Non mi piace perché fai fare da metodo alle property e questo è un 
*pessimo* vizietto di tutto mvvm.
 
 
Altro sistema: user o custom control.
* Aggiungi un tuo command al controllo
* Lo bindi al viewmodel in modo OneWayToSource
* Lo esegui dal viewmodel verso il controllo
in pratica lo usi a reverse
 
 
IMHO è un vero schifo :)
E dopo essere riuscito a risolvere il problema in entrambi i modi ti 
dico chiaramente che è bene valutare se ne vale veramente la pena o no.
Vince il sistema che è più semplice, più facile da capire per chi lo 
legge dopo che tu l'hai scritto, e più manutenibile.
 
 
Con tutte le critiche, devo anche dire che mvvm è il minore dei mali 
perché mettere tutto con gli event-handler è pure peggio :)
 
-- 
Raffaele Rialdi  
http://www.iamraf.net
 
Weblog: 
http://blogs.ugidotnet.org/raffaele
 
Microsoft MVP profile 
https://mvp.support.microsoft.com/profile/raffaele
 
UGIdotNET - 
http://www.ugidotnet.org/
 
 
 

 lecito attendersi.
 
verissimo, purtroppo M-V-VM si basa sul concetto di stato e di 
variazione dello stato per cui le property sono la scelta naturale ma i 
metodi sono un delirio che richiede forzature e compromessi spesso 
noiosi e arzigogolati. I command ogni tanto sono una buona soluzione ma 
troppo spesso sono anch'essi una mezza forzatura.



 
Sostanzialmente adotti un pattern per tradire altre best-practices 
dall'altra parte e questo rompe la mis-credenza che adottare un pattern 
implichi codice 100% clean.
 
La reale usabilità dei pattern è strettamente legata alla tecnologia 
che ci sta sotto, motivo per cui non ritengo sia un delitto 
contestualizzare certe scelte e "rompere" il pattern stesso qualora 
questa sia:
- una decisione scelta con cognizione di causa
- un reale vantaggio in termini di ciclo di vita del software


 completamente fuori strada?
 
Questo esempio non mi dispiace, non so se è "pure MVVM" ma secondo me 
serve alla "causa" (ed è simile all'approccio che hai seguito ieri in 
ufficio):
 
http://tinyurl.com/8xcvdbl
 
 
ciao

 - un reale vantaggio in termini di ciclo di vita del software
 
amen :-)
 
.m
 
-- 
blog @ //
milestone.topics.it
 
 
 

 ufficio):
[cut]
 
Effettivamente è un modo per arrivare al punto in maniera abbastanza 
rapida. Se mi permetto però, "contesto" un paio di cose che non mi 
piacciono. :-)
 
1. il command parametrico che fa switch sul tipo di comando. :-)
2. il problema "centrale" è aggirato impostando il media element come 
property del ViewModel. Non credo che la cosa sia "il male", ma per 
avere le cose ben fatte bisogna necessariamente (IMVHO) passare da un 
container IoC che gestisca l'associazione view-viewmodel (cfr. thread di 
un paio di settimane fa tra me e Mauro). Questo significa che quando 
parte un progetto, questo deve stare *SUBITO* sulle giuste direttrici. ;-)
 
Ciao,
Giulio
 
-- 
 
 
 

 parte un progetto, questo deve stare *SUBITO* sulle giuste direttrici. ;-)
 
3. ma che pena può essere testare una cosa del genere? :-)
 
Ciao,
Giulio
 
p.s. qualcosa comunque toccherà inventarsi... :-/
-- 
 
 

 Giulio
