Newsgroup: it.comp.dotnet
Titolo: MVVM: due view sullo stesso view model?

Ciao a tutti,
vi spiego il mio (ipotetico) scenario con una storiella. :-) Sono uno 
sviluppatore e sto lavorando a una versione estremamente "light" di 
visual studio in WPF: solo il Solution Explorer e l'Editor. Devo fare in 
modo che quando dal solution explorer rinomino il file Pippo.cs in 
Pluto.cs, anche la classe "Pippo" dichiarata nel file sia rinominata in 
Pluto.
A livello di modello ho che:
class ClassFile
{
	string ClassName { ... }
	string Code { ... }
}
mi chiedo:
1. è giusto tenere la visualizzazione sincronizzata usando LO STESSO 
VIEW MODEL per entrambe le view (l'editor che visualizza ClassFile.Code 
e il solution explorer che visualizza ClassFile.ClassName)?
2. in alternativa, devo far implementare INotifyPropertyChanged al mio 
oggettod i dominio? (e la cosa mi romperebbe alquanto perché MVVM è 
bello anche perché il dominio non si "sporca" con queste cose)?
3. in alternativa, uso un message broker e tutti i VM che insistono su 
una entità registrano un evento EntityChanged?
4. (altre soluzioni?)
Grazie in anticipo e buona settimana,
Giulio
-- 

 Giulio
Se le view sono diverse usare lo stesso ViewModel potrebbe portare ad 
avere delle duplicazioni, personalmente tendo ad avere 1 View= 1 
ViewModel. Se non vuoi "sporcare" il dominio con INPC "wrappa" l'entitï¿œ 
in un altrï¿œ entitï¿œ locale che la implementa(se vuoi chiamala anche 
ViewModel) e condividi questa tra i due ViewModel (explorer e code) in 
questo modo la view ï¿œ sincronizzata e riduci al minimo le duplicazioni.
Come sempre "la soluzione" non esiste, semmai ne esiste una che meglio 
si adatta allo scenario che vuoi realizzare.
HTH

 4. (altre soluzioni?)
non sapevo se girarmi e dirtelo a voce, ma usare il newsgroup è 
senz'altro molto più "nerd"...
Se può essere un esempio valido, ho visto che nel mondo mvvm la tendenza 
è sempre quella di avere un viewmodel per ogni view, anzi, capita (a me 
spesso) di avere più viewmodel per view nel caso in cui per esempio 
visualizzi oggetti o gruppi di oggetti eterogenei in una stessa view 
(pensa alle mie treeview...).
Ho visto che MVVMLight utilizza una versione di OnPropertyChanged 
(chiamata lì RaisePropertyChanged) che include un "sollevamento" normale 
dell'evento PropertyChanged e una chiamata al Messenger (incluso) che fa 
broadcast della variazione della property per tutti gli interessati 
(dunque qualunque viewmodel interessato).
My 2 cents (poi mi giro e me li ridai eh!)

 4. (altre soluzioni?)
baracchino in spiaggia? voi venite a suonare e i ci metto le bibite e i 
panini? :-)
.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

 .m
Baracchino sulla spiaggia tutta la vita!
Non so suonare ma vengo lo stesso, porto i teli mare alle bagnanti :-P

Ciao a tutti,
On 6/27/2011 4:42 PM, Giulio Petrucci wrote:
[cut]
Grazie a tutti del consiglio.
Il baracchino in spiaggia si può fare: viste le competenze, io e 
marcosabba diamo lezioni di musica, Corrado e Mauro danno lezioni di 
MVVM. ;-)
Ciao e grazie,
Giulio
-- 

 Quello che ti "interessa" è quel Wrapper<T> del secondo post :-)
Ah su questo non sono daccordo.
Non esiste un dominio puro. È e sempre sarà dipendente dal linguaggio 
con cui lo scrivi. Domain C++ != Domain C#
Se il wrapping non è pesante, la soluzione del wrapper la prediligo 
anch'io, ma se hai un dominio complesso che si sviluppa in un grado non 
ordinato il wrapping non è facile neppure con la generazione di codice, 
figuriamoci con classi helper.
La valutazione alla fine la devi fare sulla base del rapporto 
benefici/costi, perchè il wrapper complesso ha sempre un costo alto 
(manutenzione).
In pratica non mi piace una soluzione che viene adottata solo per 
motivi "estetici" sacrificando pesantemente i costi di implementazione 
e manutenzione.
-- 
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/

 manutenzione.
condivido.
Dunque:
a) mai dare torto a Raf, i punti fragola che potrei guadagnare non 
valgono mai il rischio :-)
Scherzi a parte, condivido su tutta la linea, è che domande come questa 
varrebbero 3 giorni di corso non un post e quando si risponde ad un 
post si rischia sempre di tralasciare molte cose.
La soluzione unica non c'è mai, proprio mai, quel Wrapper<T> l'ho usato 
qualche volta in produzione, l'ho usato una quantità notevole di volte 
per realizzare velocemente i design-time-data in situazioni complesse 
per far si che Blend funzionasse.
Tendo ad evitare come la peste gli automatismi che sono la manna in 
casi semplici ma quando lo scenario è vasto (o complesso) gli 
automatismi sono il male perchè sei blindato proprio negli automatismi.
Gli automatismi che "amo" invece sono quelli che mi possono permettere 
di risparmiare poche righe di codice quasi sempre semplici (penso ad 
esempio a INotifyPropertyChanged), dove però quelle poche righe di 
codice sono ripetute una quantità spaventosa di volte; anche in questo 
caso però pretendo che se su 100 volte 2 devo farle diverse non devo 
impazzire per liberarmi dell'automatismo.
In questa direzione "Compiler as Service" mi sollazza non poco, e 
spesso spero che "lui" (il papà di C#) si convinca che AOP possa essere 
un first-class-citizen valido nel framework :-)


 first-class-citizen valido nel framework :-)
quoto, ma ho paura che sia passato in secondo piano visto che nelle 
ultime conference non ne hanno più parlato.


 conference non ne hanno piï¿œ parlato.
giï¿œ... :-/


 framework sono insormontabili....maledizione :-)
generazione di codice... questa ï¿œ la soluzione secondo me
