|
|
|
![]() |
|
Strumenti |
![]() |
#1 |
Member
Iscritto dal: Mar 2010
Messaggi: 31
|
Chiarimento implementazione pattern mvc
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? |
![]() |
![]() |
![]() |
#2 |
Senior Member
Iscritto dal: Jan 2014
Messaggi: 852
|
Di solito i dati "viaggiano" all'interno di un bean, ovvero una classe che ha i metodi set e get pubblici per ciascun campo.
|
![]() |
![]() |
![]() |
#3 |
Member
Iscritto dal: Mar 2010
Messaggi: 31
|
io ho una classe utente, con i relativi metodi get e set, da avvalorare prendendoli dalla gui per bean ti riferisci a questa classe?
|
![]() |
![]() |
![]() |
#4 |
Senior Member
Iscritto dal: Jul 2005
Città: Vicenza
Messaggi: 1570
|
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. Ultima modifica di [Kendall] : 28-07-2014 alle 15:20. |
![]() |
![]() |
![]() |
#5 | |
Senior Member
Iscritto dal: Jan 2014
Messaggi: 852
|
Quote:
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. |
|
![]() |
![]() |
![]() |
#6 | ||
Member
Iscritto dal: Mar 2010
Messaggi: 31
|
Quote:
Quote:
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. |
||
![]() |
![]() |
![]() |
#7 |
Senior Member
Iscritto dal: Jan 2014
Messaggi: 852
|
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. |
![]() |
![]() |
![]() |
#8 |
Member
Iscritto dal: Mar 2010
Messaggi: 31
|
ok grazie a entrambi per i chiarimenti penso di aver finalmente capito come strutturare il tutto
|
![]() |
![]() |
![]() |
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 11:25.