Newsgroup: it.comp.java
Titolo: Swing MVC

Quanti di voi usano questa tecnica per implementare front-end grafici.
Ne vale veramente la pena! Si vede la differenza nelle prestazioni e/o 
nella riusabilita' del codice?
Ho bisogno di qualche consiglio: devo sviluppare un progetto (sul grosso), 
ho poco tempo e l'MVC dovrei studiarmelo dall'inizio.
Grazie.
Mattia.


Per quanto ne so io l'utilizzo del pattern MVC serve principalmente in fase di
analisi per creare un codice logicamente piu' ordinato ed in particolare piu'
riutilizzabile, com'e' in generale lo scopo di ogni pattern e non influenza
in alcun modo le prestazioni dei tuoi programmi. 
-- 
             -=( |LnZ| )=-
        e-mail: lnz@{aT}
iname.com
        Home-Page: 
http://lnz.cjb.net
 



L'architettura MVC e' fondamentale, sopratutto per progetti di grandi
dimensioni, ti consiglio di utilizzarla, anche perche' da studiare non
c'e' molto, la natura e' concettuale :
MODEL : La classe che implementa il modello, cioe' tutte quelle
informazioni, che riguardano strettamente gli attributi e il
comportamento di una entita' (attenzione alla coesione, eventualmente
dividi in una o piu' classi, va bene lo stesso), niente di visuale o
di specifico riguardante la visualizzazione o gli eventi. Il modello
e' una sorgente di eventi ChangeEvent di cui la VIEW ne e' un
listener. Il MODEL, e' essenzialmente un server non conosce nessuno
dell'applicazione, riceve messaggi -> esegue metodi interni -> cambia
stato; e' una scatola nera, sa solo che ci sono delle entita', che lui
conosce come ChangeListener, che vogliono essere informate dei suoi
cambiamenti di stato (queste sono le VIEW, a priori possono essercene
piu' di una).
VIEW : La rappresentazione grafica del modello, tipicamente questo e'
il widget che rappresenta il modello (tipo un JPanel, ma non e' detto,
potrebbe essere anche un JButton o qualche cosa d'altro). Ovviamente
e' questo il componente che realizza l'interfaccia grafica e che
recepisce gli eventi (comunica con l'utente). La VIEW e' un listener
del modello (Change Listener), quando il modello comunica il suo
cambiamento di stato, la VIEW, CHE CONOSCE MOLTO BENE IL 
MODELLO, in quanto ne deve dare una rappresentazione, si informa sul
suo stato, ed eventualmente rendera' visibile il cambiamento.
Secondo il modello classico la VIEW dovrebbe essere listener di tutti
quegli eventi (generati da lei stessa, in quanto widget) che la
cambiano direttamente, cioe' che cambiano direttamente la
visualizzazione del modello, indipendentemente dallo stato del modello
stesso.
CONTROLLER : Il mediatore fra il modello e la vista, regola il flusso
di eventi dalla vista (che li genera), al modello (che, a seconda del
suo stato, reagisce di conseguenza). Il controller quindi si registra
per tutti gli eventi generati dalla vista, li interpreta sematicamente
per il modello, e comunica attraverso dei messaggi (chiamate di
metodi) al modello (Il CONTROLLER conosce molto bene, nella sua 
natura implementativa il modello), che reagira' secondo programma.
[Consiglio, quando dovrai legare le varie entita', cioe' dovrai
assegnare alla vista un modello, o registrare la vista come listener
presso il modello ecc..; cerca di farlo fare ad una entita' esterna, e
non internamente all'MVC, altrimenti il tutto non serve a niente.
Potresti demandare la responsabilita' di farlo, ad una entita' (tipo
il JFrame stesso che contiene l'ipotetico JPanel) che potrebbe
direttamente creare anche tutte le classi dell'MVC. Questo e' il
Pattern Mediator]
Questa e' l'architettura classica, che come spesso avviene, e' poco
applicata nella pratica, perche' dovrebbe servire a disaccoppiare il
modello dalla vista in modo che ci possano essere piu' viste per ogni
modello, e nel contempo, se devi cambiare la visualizzazione del
modello, non devi metterti a modificare nulla del modello stesso
ecc...
Ma il costo e' alto, infatti il controller, deve conoscere molto bene
la vista e come questa interpreta il modello, per valutare
semanticamente gli eventi della vista stessa : come faccio io
controller a sapere a cosa corrisponde una selezione in una checkbox
in termini di eventi per il modello, se non so cosa rappresenta quella
checkbox? Ne deriva che per ogni vista ci deve essere un controller
separato, e che ogni cambiamento alla vista implica un cambiameto al
controller. TROPPO SBATTIMENTO!!! 
Quello che si fa nella pratica ;-}
Se ritieni che il controller possa assumersi responsabilita' maggiori,
uguali per tutte le viste (tipo tenere il conto del numero di
particolari eventi, cosa che accade nelle architetture Three-tier che
usano questa architettura) allora ti conviene far interpretare
semanticamente gli eventi della vista alla vista stessa (che tanto
conosce gia' molto bene il modello), la quale si registrerebbe come
listener di tutti i suoi eventi, e ne scatenerebbe di altri
(semantici, ovvero significativi per il modello stesso, ex
selezionePezzo(int riga, int colonna)), comunicandoli al controller,
il quale dopo le debite elaborazioni comunichera' la cosa al modello
(a te la decisione se queste elaborazioni sono necessarie o meno, vedi
soluzione 2).
Se ritieni che il controller non debba fare niente altro che fare da
wrapper ai messaggi delle viste nei confronti del modello, tanto vale
(dato che le viste conoscono bene il modello) fare come prima, cioe'
l'interpretazione sematica degli eventi sempre alle viste, ma questa
volta unire vista e controller, quindi sara' direttamente la vista a
spedire messaggi al modello (Questo e' quello che e' stato fatto dalla
sun per i widget swing).
Spero di averti chiarito un po' il concetto, comunque per le persone
che sono interessate a questo argomento, o ad altri riguardanti la
programmazione OO, con un occhio particolare alle architetture del
software, sto aprendo una nuova area sul sito di redangel
(
www.redangel.it
), dove ci saranno articoli, progetti e forum di
discussione. Tutti sono invitati a partecipare! (occhio, non e' spam,
non si guadagna niente, non si vince niente, si rischia solo di
imparare)
					Gabriele "SunGray" Lana