Newsgroup: it.comp.dotnet
Titolo: Validazione del modello in un contesto MVVM

Ciao a tutti,
mi trovo nel seguente scenario: un editor di grafi realizzato in WPF. 
Ogni nodo ha un nome, due figli dello stesso nodo non possono avere lo 
stesso nome. A livello di business posso esprimere la cosa come:
class Node {
	string Name { ... }
	List<Node> Children { get; }
}
class NodeService
{
	AddChild(Node root, Node child)
	{
		var omonimo = root.Children.FirstOrDefault(n => n.Name == child.Name);
		if (omonimo != null && omonimo != child)
			throw new InvalidOperationException();
		root.Children.Add(child)
	}
}
Sto cercando di immaginare l'interazione con l'utente:
1. l'utente clicca di destro sul nodo 'A' che ha già due figli 'B' e 'C'
2. dal menù contestuale sceglie "Add Child" ->
	2.1 sotto al nodo A appare un nodo senza nome che prende il focus,
3. l'utente scrive 'C' e preme invio;
4. visto che il nome non è ammesso (esiste un "fratello" con lo stesso 
nome), il livello di business solleva una InvalidOperationException
5. all'utene viene mostrato un popup con il messaggio di errore
6. si torna al punto 2.1
7. l'utente scrive 'D' e preme invio
8. il nuovo nodo viene aggiunto... e tutti vissero felici e contenti.
Ora, faccio davero fatica a capire come il livello dei view-model possa 
interagire con questo modello, tenendo conto che per ogni nodo 
visualizzato c'è un NodeViewModel che insiste su un oggetto Node.
Qualcuno mi da una mano?
:-)
Ciao e grazie,
Giulio
-- 

 :-)
Io ritengo ci sia la necessità di avere due distinti livelli:
- il viewmodel impedisce che il modello possa divenire invalido. In 
sostanza quando l'utente tenta di dare un nome omonimo, non permette di 
impostarlo e lo marca come invalido usando il meccanismo di validzione 
grafico di wpf.
- al modello tocca un controllo più 'sostanziale' e rigido, la cui 
incoerenza fa scattare un eccezione che ti obbliga di tornare indietro 
sui tuoi passi (ricarichi l'ultima situazione valida tramite undo o da 
db). Questo serve solo a garantire la consistenza dei dati e, almeno in 
teoria, non dovrebbe mai intervenire se non perché uno smart-user ha 
'gabbato' la UI.
Per il primo sistema puoi guardare la validazione wpf da triggerare 
durante la digitazione. Di default viene mostrato un rettangolo rosso 
attorno al controllo ma puoi impostare quello che vuoi (anche uno user 
control con tutti i dettagli del caso).
-- 
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/

 db).
La prima "obiezione" (violando quindi il principio per cui "Raf ha 
sempre ragione" :-p) è questa: ma in questo modo non dovrei "duplicare" 
i controlli? Se la regola di business che sottosta alla validazione 
dovesse cambiare dovrei cambiare a mano codice diverso in due punti... e 
considerando il numero di regole con cui avrò a che fare nel caso reale, 
la cosa mi "abbatte"... :-D
Ciao,
Giulio
-- 

 "abbatte"... :-D
Dipende dal contesto specifico ma il tipo di validazione non è proprio 
uguale anche se potresti avere qualcosa in comune (quindi condivisibile 
per minimizzare quel problema).
Sul lato UI:
- fai i controlli man mano che i dati vengono inseriti ma il modello 
non è ancora completo, quindi può capitare che l'inserimento di un 
altro campo renda invalido il precedente.
- potresti non lavorare direttamente sul modello ma su dei DTO. A causa 
della differenza la validazione sarebbe necessariamente differente 
rispetto al modello che poi viene persistito.
- puoi voler restringere l'usabilità del modello anche se questo 
rimarrebbe comunque conforme. Per esempio in un front-end web potresti 
non supportare una naming convention perchè implicherebbe un numero di 
feature che non hai previsto.
Sul lato 'server':
- la validazione deve essere semplice e limitarsi a dare un responso 
booleano (eventualmente loggando i dettagli). La semplicità è 
essenziale per evitare di corrompere il modello.
- potresti avere maggiori dati a disposizione per eseguire una 
validazione di più basso livello. Per esempio una query su db.
Ho buttato giù le prime che mi sono venute in mente, non so quanto 
siano aderenti al tuo caso, ma sono scampoli di memorie di lavori 
passati :)


 per evitare di corrompere il modello.
Quindi dici meglio il risultato booleano che una bella eccezione?


 Quindi dici meglio il risultato booleano che una bella eccezione?
beh la validazione spara un booleano, poi se vuoi sollevare l'eccezione 
lo puoi chiaramente fare ed è sicuramente il caso se hai passato le 
validazioni ui ma non quelle lato server.
Ciao


 
Vuoi una risposta "estetica" o "pragmatica"? :-)
P.S.: sono in ferie: qualunque sia la tua scelta, risponderò cmq sett prox
:-)

 :-)
Goditi le ferie. :-)
Ci sentiamo prossimamente!
Grazie,
Giulio
-- 

 :-)
 
Recentemente mi sono riletto il thread e... tornato dalle ferie? ;-)
 
Ciao,
Giulio
 
--
 
 
 


 
LOL! Vieni al DDD Day (
http://www.ddd-day.it
) sabato e ne parliamo? :-)
 
 
-- 
.A
GUISA - 
http://www.guisa.org
 
UGIdotNET - 
http://www.ugidotnet.org
 
Read my blog at: 
http://blogs.ugidotnet.org/pape
 

 LOL! Vieni al DDD Day (
http://www.ddd-day.it
) sabato e ne parliamo? :-)
 
LOL!
Qui in azienda se ne stava parlando, il problema - per quanto riguarda 
il sottoscritto - è che sabato si sposa un mio amico. :-)
BTW: pubblicate webcast/slides?
 
Ciao,
Giulio
 
-- 
 
 
 

 BTW: pubblicate webcast/slides?
le slide sicuramente si, ci stiamo organizzando per registrare le 
sessioni: incrocia i "diti" :-)
