Su MVC diverse viste hanno lo stesso controller o una vista deve avere un unico controller?

Il problema è che il pattern MVC è stato progettato in un sistema che in realtà non esiste più. È stato inventato in Smalltalk in un momento in cui le librerie UI non esistevano. Per creare una finestra di dialogo hai disegnato tutte le caselle, evidenziato i quadrati appropriati, assicurati che il testo che stavi disegnando finisse nel punto giusto ... ecc ...

Immagina come sarebbe scrivere un'app di dialogo usando nient'altro che una grande tela. Questo è il mondo da cui proviene MVC.

Una "vista" in questo sistema era una casella di testo ed era una classe che era responsabile del disegno della scatola, del testo, del disegno delle aree selezionate, della risposta alle modifiche nel testo, ecc ...

Un "controller" era un'altra classe che prendeva gli eventi del mouse che si verificavano all'interno di questa finestra come il movimento del mouse, la chiave giù, la chiave, i clic, ecc ... e decise cosa accadde. Dovremmo cambiare il testo? Dovremmo cambiare la selezione? Cose del genere.

Un "modello" era un'altra classe che rappresentava i dati di base e lo stato del componente. Un modello di casella di testo dovrebbe avere il testo, il carattere, la selezione, ecc.

Come puoi vedere, in una situazione come questa le tre componenti sono molto impigliate nella rappresentazione di una singola idea. In questo contesto ha senso parlare di "triade".

Oggi, se stai lavorando alla creazione di una libreria dell'interfaccia utente e utilizzando i comandi di disegno grezzi, potresti fare qualcosa di simile. Ma l'applicazione del modello "MVC" si è diffusa oltre il suo scopo iniziale. Ora a giorni hai una "vista" che potrebbe essere in realtà una finestra di dialogo completa e un controller che risponde a eventi come "textChanged" o "buttonClicked". Il modello nell'odierno MVC è normalmente qualcosa di abbastanza disconnesso dal sistema (ma generalmente collegato alla vista fornendo un'interfaccia di un osservatore di qualche tipo) e potrebbero esserci molte viste associate a un modello.

In un sistema che ho architettato di recente, ad esempio, abbiamo avuto circa 10+ visualizzazioni tutte osservando un singolo documento "titolare" e il suo documento attivo. Un'interfaccia di disegno principale interagiva con il layout del documento, varie viste di proprietà che osservavano l'elemento selezionato e fornivano un'interfaccia di registrazione, e una rappresentazione in scala ridotta della vista principale che mostrava l'intero documento invece della sola finestra visibile. Alcune di queste viste avevano controller di varia complessità che trasformavano gli eventi della GUI in modifiche al documento, che a sua volta avrebbe notificato le varie visualizzazioni.

Puoi ancora chiamare una tale relazione una "triade"? Forse, ma penso che implichi troppo della precedente, vecchia applicazione di MVC.

Potresti condividere i controller con diverse viste? Dipende da quanto sono simili le visualizzazioni. Ho scoperto che in generale questo tipo di oggetto ha un comportamento specifico alla vista che sta controllando E il modello che sta manipolando è molto riutilizzabile ... ma ci sono sempre delle eccezioni.

Dipende. Esistono diverse varianti di MVC, alcune in cui solo una relazione 1: 1 ha senso (come "l'umile finestra di dialogo"), altre in cui questo non è il caso. Vorrei raccomandare di leggere " Build Your Own CAB "serie di articoli, spiegando le varianti MVC più importanti.

Le viste non hanno controller in MVC. Il controller è il capo, quindi un controllore decide quale vista deve essere sottoposta a rendering e le viste non / non possono importare quale controller abbia richiesto la vista.

Puoi / avrai assolutamente più viste da un controller. Pensa solo a creare un modello per ciascuna vista se vuoi seguire il pattern MVC.

Il punto del controller è controllare le interazioni dell'utente con il tuo modello di dominio - cioè, è un livello di indirezione tra ciò che l'utente vede (la vista) e lo stato delle tue applicazioni (il modello).

Quando l'utente effettua una richiesta, viene indirizzato a un controller. Il controllore decide come inoltrare tale richiesta all'applicazione, di solito attraverso una sorta di classe di servizio. Quindi interpreta la risposta da quella classe di servizio e decide quale vista restituire all'utente.

Un controller può sempre restituire la stessa vista (1: 1) se c'è un solo tipo di richiesta che l'utente può fare del controller e richiede sempre lo stesso tipo di risposta. Ad esempio, HelloWorldController restituirà sempre un HelloWorldView che mostra "Hello, World!"

D'altra parte, un controllore deve spesso decidere su diverse viste, a seconda di ciò che il modello dice. Il TeamRosterController potrebbe restituire un RugbyTeamRosterView o un FootbalTeamRosterView , a seconda del tipo di team richiesto.

In genere è preferibile che i controllori siano apolidi, sebbene possa essere necessario o desiderabile un accesso allo stato della sessione utente. Dovresti gestire l'accesso a tale stato separatamente, se possibile.

Consiglio vivamente di guardare un vero quadro MVC per vedere cosa fa e come funziona. Non devi usarlo, ma otterrai sicuramente una migliore comprensione prima di crearne uno tuo.