[OOP] Dubbio sul pattern MVC

[mcaisco]

Salve,

ho un dubbio sul pattern MVC.
Teoricamente il Controller dovrebbe gestire in delega le azioni fatte dall'utente sulla View, interagendo con il Model e magari cambiandolo.
Il mio dubbio e' nella reale interazione fra View e Controller. Fino a quando un'azione sulla View, passando attraverso il Controller, modifica qualcosa nel Model e, magari tramite il pattern Observer, il Model aggiorna la View fila tutto liscio.

Ma se un'azione sulla View non ha alcun effetto sul Model ma deve comunque aggiornare qualcosa sulla View? L'utente fa qualche azione sulla View, la View chiama il Controller per gestire la chiamata, il Controller fa le sue belle cosine e poi magari si trova a dover aggiornare qualcosa nella View anche se il Model non e' stato modificato.

La situazione potrebbe sembrare strana ma non lo e' poi cosi' tanto.
Un caso tipico per esempio e' quando in reazione a qualche azione dell'utente sulla View bisogna solo abilitare/disabilitare qualche oggetto grafico della View. Ad esempio un gruppo di radio buttons: a seconda del radio button selezionato, gli altri dovrebbe disabilitare qualcosa.
La selezione di un radio button andrebbe gestita nel Controller, che si ritroverebbe semplicemente a dover disabilitare/abilitare elementi grafici nella View, senza che ci sia nessuna modifica nel Model.
Come si potrebbe gestire una situazione del genere?

[banryu79]

Non so se ci sono delle "best practices" codificate, però anche io mi sono trovato in casi come questo.

A seconda della complessità della cosa io fin'ora ho fatto così:
- caso "semplice" (tipo quello che hai descritto tu):
Dato che non c'è interazione tra View e Model, ma avviene una modifica di stato della View in risposta ad una modifica della View stessa da parte dell'utente, che coinvolge solo se stessa, ho scelto di codificare la logica che rappresenta questo meccanismo nella View.
Non è altro che una transizione di stato della sola View, che ha l'obiettivo di fornire una rappresentazione più adeguata di se stessa, non del Model sottostante, per motivi funzionali.

- caso "non semplice"
Esempio: in un'applicazione MDI, dove i diversi frame interni aperti sono legati da una logica genitore-figlio, e quando si chiude un figlio si vogliono ripristinare tutti i genitori della catena eventualmente aperti e iconizzati o, viceversa, quando si chiude un genitore si vogliono chiudere tutti i figli della catena eventualmente aperti.
Anche qui non c'è interazione tra View e Model e ho già un Controller associato a ogni View; la modifica della View da parte dell'utente non coinvolge il Model, ma non coinvolge più nemmeno la singola View che subisce l'azione-utente: potrebbe coinvolgere altre View.
In questo caso ho astratto un ulteriore Controller "supervisore" che viene istanziato dal Controller "normale", il quale lo usa come delegato per alcune responsabilità.
Al Controller "supervisore", nel mio caso, viene delegata l'operazione di apertura e chiusura della View associata al Controller "normale", oltre a tenere registrate le View "figlie" della View associata al Controller "normale".

[mcaisco]

Ho capito...

Comunque nel tuo caso, effettivamente la soluzione e' stata "semplice" perche' comunque tramite il controller supervisore dovevi mantenere traccia delle varie View collegate e chiuderle, quindi l'operazione era sulla View stessa, cioe' dovevi richiamare un metodo close() su ogni View.

Il caso "semplice" da me prospettato e' in realta' piuttosto bastardo. Io ipotizzo infatti che non il Controller debba aggiornare qualcosa della View, ma teoricamente non ha accesso a quel qualcosa.
Inoltre non e' detto che l'azione sulla View debba essere solo una modifica a se stessa, ma potrebbe comunque dover passare tramite il Controller, il quale fara' alcune operazioni ma sempre senza interagire con il Model, e poi aggiornare in base a qualche criterio la View. Quindi il caso e' semplice fino ad un certo punto. Ci puo' essere comunque una parte di elaborazione da parte del Controller il quale deve decidere in che modo riaggiornare la View.

Sembra quasi che la soluzione sia che la View esponga alcuni suoi campi come pubblici in modo che il Controller possa agire su di essi.
Questo e' parzialmente errato secondo me in base allo schema MVC.
Inoltre non e' neppure cosi' pulito perche' se in una View ho N elementi grafici, potrei teoricamente doverli esporre tutti come pubblici, oppure implementare fino a N metodi pubblici che permettano di modificare quei campi. Sta cosa e' tutt'altro che pulita!