[MVC] Come istanziare Model View e Controller

[tomminno]

Qual è il modo corretto di istanziare i componenti dell'MVC?
Chi deve istanziare il Model? Il Controller o il chiamante?
E il View?
Inoltre il View cosa riceve come parametri il Model e il Controller, solo il Controller e recupera il Model dal Controller, o altro?
Dato che generalmente il View è un componente grafico e ha bisogno di un riferimento alla finestra padre questo dovrebbe essere istanziato dal chiamante giusto? Altrimenti il controller dovrebbe avere conoscenze sull'interfaccia grafica utilizzata e non credo sia il caso.

E in caso di modifiche, il View segnala al Controller l'evento e poi il controller recupera i dati dal View, oppure il view passa direttamente i dati al Controller che poi provvede a modificare il Model?

[tomminno]

Proprio nessuno ha qualche suggerimento su come istanziare gli elementi dell'MVC?

[tglman]

di solito l'approccio è il view presenta i dati leggendo dal model, ed usa il controller per eseguire le operazioni, incluse le operazioni di recupero del model.
per quento riguarda le operazioni di modifica e il viè che passa i parametri al controller!!

[tomminno]

di solito l'approccio è il view presenta i dati leggendo dal model, ed usa il controller per eseguire le operazioni, incluse le operazioni di recupero del model.
per quento riguarda le operazioni di modifica e il viè che passa i parametri al controller!!

La mia domanda non era su come funziona l'MVC ma su come istanziare i vari componenti dell'MVC.

Chi e come istanzia il Model, il View e il Controller?

[Mazzulatore]

La mia domanda non era su come funziona l'MVC ma su come istanziare i vari componenti dell'MVC.

Chi e come istanzia il Model, il View e il Controller?

MVC è un ideale approccio, non un disegno specifico, e caso per caso prende forme diverse.

per esempio in SWING:
Model, controller e view (o ViewFactory) (nel caso più difficile) sono istanziati direttamente, model è l'interfaccia per presentare i dati al controller che si occupa di programmare le view ed aggiornarle e ricavarne gli eventi. EDIT: che vengono trasformati in chiamate ai metodi di model per modificare i dati.
Controller contiene al suo interno Model, e le view, o le factory delle view passati come parametri a seconda delle circostanze nel costruttore o successivamente.
Se non consideri la view perchè vuoi usare quelle predefinite il controller se le istanzia da solo.
Detto così è troppo semplificato e poco corretto perchè... dipende infine da come lo usi :) guarda ad esempio come funziona JTree nella API di swing e come passargli un oggetto che implementa treemodel.

Ma in che ambito ti serve?

[tomminno]

MVC è un ideale approccio, non un disegno specifico, e caso per caso prende forme diverse.

per esempio in SWING:
Model, controller e view (o ViewFactory) (nel caso più difficile) sono istanziati direttamente, model è l'interfaccia per presentare i dati al controller che si occupa di programmare le view ed aggiornarle e ricavarne gli eventi. EDIT: che vengono trasformati in chiamate ai metodi di model per modificare i dati.
Controller contiene al suo interno Model, e le view, o le factory delle view passati come parametri a seconda delle circostanze nel costruttore o successivamente.
Se non consideri la view perchè vuoi usare quelle predefinite il controller se le istanzia da solo.
Detto così è troppo semplificato e poco corretto perchè... dipende infine da come lo usi :) guarda ad esempio come funziona JTree nella API di swing e come passargli un oggetto che implementa treemodel.

Ma in che ambito ti serve?

Lo stavo guardando per applicarlo a WinForms (C#) o wxWidgets (C++).
Il View in sostanza dovrebbe avere un riferimento in sola lettura al Model, in quanto deve solo visualizzarne i dati mentre per modificarlo deve passare tramite il Controller.
La teoria dell'MVC afferma che l'utente dovrebbe interagire tramite il Controller, ma per come sono fatte le suddette interfacce l'utente deve per forza interagire con il View, in quanto gli eventi scatenati dall'utente vengono intercettati da metodi del View.

Come struttura pensavo che nel Main viene istanziato un Controller, il quale a sua volta istanzia internamente il Model e il View passandogli un riferimento in sola lettura al Model.

Però a runtime il View per eseguire correttamente deve istanziare un nuovo Model (penso al classico tasto "Applica" in cui tutti i dati devono essere salvati, mentre il View rimane aperto), passarlo come parametro dell'evento al Controller il quale applica le modifiche al Model corrente, con conseguente aggiornamento del View.

La struttura poi si può complicare ulteriormente tramite Mediator per la comunicazione tra vari Controller che sicuramente sono presenti nell'applicativo, ma questo esula in qualche modo dall'MVC base.

[Mazzulatore]

Lo stavo guardando per applicarlo a WinForms (C#) o wxWidgets (C++).
Il View in sostanza dovrebbe avere un riferimento in sola lettura al Model, in quanto deve solo visualizzarne i dati mentre per modificarlo deve passare tramite il Controller.
La teoria dell'MVC afferma che l'utente dovrebbe interagire tramite il Controller, ma per come sono fatte le suddette interfacce l'utente deve per forza interagire con il View, in quanto gli eventi scatenati dall'utente vengono intercettati da metodi del View.

Come struttura pensavo che nel Main viene istanziato un Controller, il quale a sua volta istanzia internamente il Model e il View passandogli un riferimento in sola lettura al Model.

Però a runtime il View per eseguire correttamente deve istanziare un nuovo Model (penso al classico tasto "Applica" in cui tutti i dati devono essere salvati, mentre il View rimane aperto), passarlo come parametro dell'evento al Controller il quale applica le modifiche al Model corrente, con conseguente aggiornamento del View.

La struttura poi si può complicare ulteriormente tramite Mediator per la comunicazione tra vari Controller che sicuramente sono presenti nell'applicativo, ma questo esula in qualche modo dall'MVC base.
Eh insomma, puoi fare come vuoi alla fine.... sicuramente "Però a runtime il View per eseguire correttamente deve istanziare un nuovo Model " non porta molti benefici in quanto non isoli le informazioni di logica.
Senti qua se ti piace:
(Sempre ispirandomi a swing semplificato all'inverosimile)
Il vero controller è Model, un wrapper vero e proprio dei tuoi dati che espone la parte interessante ai fini della visualizzazione (vedi TreeModel). Esso contiene i metodi per la modifica basati sugli eventi che immagini provengano dalla vista (edit item name, remove item, add item).
View è il controller del componente vero e proprio di rendering, cattura gli eventi e richiema i listener registrati dal controller.
View, per semplificare può leggere direttamente da model attraverso i parametri esposti, gli eventi provenienti da view sono passati al controller attraverso più delegate, function pointer, inner class come ti pare, previa registrazione.

Controller coordina il tutto...

Ma prima istanzi Model tipo MyModel model = new MyModel(myDataCollection);

Poi view MyView view = new MyView(myGraphicComponent);
oppure puoi ereditare, se puoi dalla classe graphic component ed avere:
MyView view = new MyView();

poi MyController controller = new MyController(myModel, myView);
nel costruttore di mycontroller ci sarà un myView.setModel(myModel);

In swing la View utilizza il controller per leggere, infatti JTree ha parecchi metodi pubblici per leggere i dati dal model, cambiare la vista o modificare i dati. in questo modo ti basta ereditare da JTree e fare overloading dei metodi per cambiarne il comportamento.
Inoltre anche Model ha dei listener list per notificare al controller che i dati sono stati modificati fuori dal contesto MVC.
C'è molto gioco di listener e molto codice da scrivere ma è un buon esercizio ;)
EDIT: In questi esempi per ogni parametro dei costruttori c'è una proprietà della classe che manterrà quel valore per tutta la vita dell'oggetto.

[tomminno]

Eh insomma, puoi fare come vuoi alla fine.... sicuramente "Però a runtime il View per eseguire correttamente deve istanziare un nuovo Model " non porta molti benefici in quanto non isoli le informazioni di logica.


Se non fai così e hai un Model (inteso come classe contenitore delle informazioni da mostrare, senza chiaramente tutta la Business logic) con 4 campi stringa (per fare un esempio), l'evento associato all'ipotetico tasto "Applica" deve passare 4 stringhe, il giorno che il Model avrà 5 stringhe devi cambiare interfaccia per gestire il nuovo elemento, se passi un Model eviti per lo meno di mettere mano all'interfaccia ad ogni aggiornamento.
Poi sarà il controller a gestire i singoli campi.

Certo che in questo modo la validazione dei dati viene decisamente più complessa, ci vuole un'eccezione diversa per ogni elemento mostrato per la segnalazione di eventuali valori non validi (penso al classico * accanto al campo non valido), che a questo punto deve essere fatta dal Controller.

E nel web? In teoria i controlli javascript vanno contro l'MVC perchè accoppiano View e logica.
E' anche vero che usare una chiamata Ajax ad ogni azione sulla pagina per chiedere al controller di validarla è un suicidio.


Controller coordina il tutto...

Ma prima istanzi Model tipo MyModel model = new MyModel(myDataCollection);

Poi view MyView view = new MyView(myGraphicComponent);
oppure puoi ereditare, se puoi dalla classe graphic component ed avere:
MyView view = new MyView();

poi MyController controller = new MyController(myModel, myView);
nel costruttore di mycontroller ci sarà un myView.setModel(myModel);


Stavo guardando ASP.NET MVC e mi pare che al Controller venga passato un ViewFactory. Quello che non mi torna è il passaggio del Model. Non dovrebbe essere il Controller ad istanziarlo internamente?


In swing la View utilizza il controller per leggere, infatti JTree ha parecchi metodi pubblici per leggere i dati dal model, cambiare la vista o modificare i dati. in questo modo ti basta ereditare da JTree e fare overloading dei metodi per cambiarne il comportamento.
Inoltre anche Model ha dei listener list per notificare al controller che i dati sono stati modificati fuori dal contesto MVC.


Da quello che avevo capito il View accedeva direttamente al Model in lettura, mentre passava dal controller per la scrittura, se invece deve passare sempre dal Controller è inutile che mantenga un riferimento al Model, non lo userebbe mai.