Chiarimento implementazione pattern mvc

[ste89]

Salve a tutti
dovrei realizzare un applicazione client e server in java, per un esame all'universita'. Leggendo i vari design pattern sono arrivato alla conclusione che il model-view-controller si quello adatto all'applicazione che dovrei creare. Ho un po' di dubbi sull'implementazione di tale pattern.
Ho gia' creato le interfacce grafiche e all'interno ho inserito una classe innestata (privata) per la gestione degli eventi, ho creato il lato server che si occupa solo della comunicazione con il database cioe' ho scritto due metodi per le query(e dovrebbe fare la parte del model). Il problema principale e' il controller non riesco a capire come gestire, leggendo anche altri post nel forum con questo pattern i controlli sui dati inseriti dovrei farli nella classe controller e non nella view, ma mi chiedo come faccio a passarglieli se sono tutti privati i campi?

[Daniels118]

Di solito i dati "viaggiano" all'interno di un bean, ovvero una classe che ha i metodi set e get pubblici per ciascun campo.

[ste89]

io ho una classe utente, con i relativi metodi get e set, da avvalorare prendendoli dalla gui per bean ti riferisci a questa classe?

[[Kendall]]

Allora, solitamente nel pattern MVC (che è bene o male lo standard per quanto riguarda la programmazione di applicativi con interfaccia grafica), il "Model" sono per l'appunto tutte le classi che strutturano il tuo modello dati. Queste non hanno alcun riferimento (o comunque non dovrebbero averlo) ad altri "mattoni" del tuo programma. Sono unità stand-alone che eseguono solo il loro compito. Gestiscono i dati, effettuano operazioni su di esso, caricano, salvano, e via discorrendo.

Le View sono i puri oggetti grafici, con il solo ed unico scopo di presentare a schermo una rappresentazioni visuale del modello.
Gli oggetti grafici sono eredi delle classiche classi base View, UIView, PincoPallinoView (in base a come vengono chiamate nel framework di turno).
Possono essere create programmaticamente o essere generate da file di markup tipo xml, xaml, qml o altro, in maniera tale da poter "disegnare" l'interfaccia in maniera interattiva tramite i tool messi a disposizione dal produttore del framework. (La classica situazione in cui hai il tuo bel canvas e ci trascini dentro pulsanti, campi di testo, layout e chi più ne ha più ne metta).

I Controller sono invece la parte strutturale del programma. Spesso e volentieri nei Controller tieni riferimenti agli oggetti grafici, nonchè agli oggetti del tuo Data Model. e tramite il controller li fai dialogare tra di loro.
Per esempio quando definisci un evento, per esempio la pressione di un bottone, lo vai a fare nel controller, e tale evento andrà a scatenare un qualche effetto sul tuo modello dati, o a modificare altre parti della tua interfaccia (se il suo compito - quello del pulsante intendo - è puramente visuale, per esempio far apparire un popup).

La natura dei Controller però dipende molto dal framework che usi per la presentazione.

Nella programmazione iOS per esempio esistono classi dedicate chiate ViewController, che fanno da ponte tra la view e il modello dati.

Nella programmazione Android i controller trovano la loro incarnazione nelle Activity e nei Fragment (anche se svolgono altre funzioni ben più strutturali di un semplice Controller).

Nel tuo caso dipende da quello che stai usando per il tuo programma.

La natura del controller non è comunque sempre ben definita. O meglio, in base a come è stato strutturato il framework di turno può assumere connotazioni abbastanza diverse e non sempre riconducibili ad un unica definizione.

[Daniels118]

Originariamente inviato da ste89

io ho una classe utente, con i relativi metodi get e set, da avvalorare prendendoli dalla gui per bean ti riferisci a questa classe?

No, il bean è un oggetto semplice che deve contenere i soli campi relativi ai dati che vuoi scambiare con la view. Ti faccio due semplici esempi: supponiamo che tu voglia fare una schermata di login, allora costruirai un bean con due campi, id_utente e password (e relativi metodi get e set). In una seconda schermata vuoi visualizzare l'elenco degli accessi dell'utente, avrai quindi una lista di bean "AccessoBean" che avranno dei campi tipo data, ora e ip.
Come vedi in nessuno dei due casi abbiamo passato l'oggetto di classe Utente alla view.
Il controller ha lo scopo di trasportare i dati tra view e model, ed implementare la logica delle varie procedure che costituiscono l'applicazione. Ovviamente nulla ti vieta di passare un business object direttamente alla view, però così facendo perdi delle funzionalità. Se ad esempio fai una schermata per la modifica dei dati dell'utente e passi l'oggetto di classe Utente alla view, gli attributi verranno modificati direttamente senza darti prima la possibilità di validarli. Il modo corretto invece è creare un bean "DatiUtenteBean" che consente di portare i dati dalla view al controller, quindi validarli, e se sono coerenti il controller li copia sul model.

[ste89]

Spesso e volentieri nei Controller tieni riferimenti agli oggetti grafici, e tramite il controller li fai dialogare tra di loro.

Scusa Kendall potresti chiarimi questo fatto, cioe' creo l'interfaccia, come hai detto con quello che voglio xml.. e quant'altro (utilizzo il plugins windows builder in eclipse) per correttezza tutti gli oggetti grafici sono dichiarati come attributi privati della classe, che realizza la view(jframe). Come fa' il controller ad avere dei riferimenti agli oggetti?

Per esempio quando definisci un evento, per esempio la pressione di un bottone, lo vai a fare nel controller, e tale evento andrà a scatenare un qualche effetto sul tuo modello dati, o a modificare altre parti della tua interfaccia (se il suo compito - quello del pulsante intendo - è puramente visuale, per esempio far apparire un popup).

In questo esempio ok ho il riferimento dell'oggetto che ha scaturito l'evento ma poi tutti gli altri oggetti? non so' per esempio campi di testo e quant'altro? come faccio ad averne rifermento ed ad utiizzarli?

Il mio problema e' proprio la comunicazione tra le varie parti view e controll non tanto il model perche' come hai accennato funziona in maniera indipendente o per meglio dire quando viene chiamato.(utilizzo semplicemte gli oggetti swing, se non ho capito male utilizzano il pattern observer).

Daniels118 scusa la mia ignoranza, se non ho capito male mi suggerisci di creare delle classi adhoc proprio per il trasfermento dei dati da un componente ad un'altro giusto?
Es. se ho un'interfaccia di registrazione di un utente, creo una classe dove inserire tutti i dati la passo al controll che poi effetura i controlli sui dati, se sono giusti, li passa al model atrimenti li rifiuta giusto? e cosi per ogni schermata?

Scusate ancora ho bisogno di un altro chiarimento per quello che ho letto, potrei anche far comunicare direttamente model e view direttamente senza passare dal controll, cioe' volevo creare un interfaccia che quando la creo mostra gia' al suo interno dei valori.

[Daniels118]

Deve esserci per forza un controller che, allo scaturirsi di un evento (richiesta dell'utente), legge i dati dal model e li inserisce nella view.
Per far leggere i dati direttamente alla view dovresti cablare nella view i metodi di accesso al model, perdendo quella separazione che offre il pattern mvc.
Così facendo:
- perderesti la riusabilità della view, perché sarebbero cablate per quello specifico model;
- faresti un miscuglio di codice per la gestione grafica e logica, rendendone difficile l'interpretazione.

Il fatto di fare una classe ad hoc per scambiare i dati ti consente di avere un'interfaccia ben definita tra view e controller, però volendo puoi anche utilizzare delle Map. Sarebbe anche possibile passare ogni campo come un parametro distinto nei metodi, ma potrebbero venire delle firme lunghissime, che oltre ad essere brutte, vanno ad inficiare sullo stack.

[ste89]

ok grazie a entrambi per i chiarimenti penso di aver finalmente capito come strutturare il tutto