Il problema MVCè che le persone pensano che la vista, il controller e il modello debbano essere il più indipendenti possibile l'uno dall'altro. Non lo fanno - una vista e un controller sono spesso intrecciati - la pensano come M(VC).
Il controller è il meccanismo di input dell'interfaccia utente, che è spesso aggrovigliato nella vista, in particolare con le GUI. Tuttavia, la visualizzazione viene emessa e il controller viene immesso. Una vista può spesso funzionare senza un controller corrispondente, ma un controller è di solito molto meno utile senza una vista. I controller intuitivi utilizzano la vista per interpretare l'input dell'utente in modo più significativo e intuitivo. Questo è ciò che rende difficile separare il concetto di controller dalla vista.
Pensa a un robot radiocomandato su un campo di rilevamento in una scatola sigillata come modello.
Il modello è incentrato sulle transizioni di stato e stato senza alcun concetto di output (display) o su ciò che sta innescando le transizioni di stato. Posso ottenere la posizione del robot sul campo e il robot sa come spostare la posizione (fare un passo avanti / indietro / sinistra / destra. Facile da immaginare senza una vista o un controller, ma non fa nulla di utile
Pensa a una vista senza controller, ad esempio qualcuno in un'altra stanza della rete in un'altra stanza che osserva la posizione del robot mentre le coordinate (x, y) scorrono lungo una console a scorrimento. Questa vista mostra solo lo stato del modello, ma questo ragazzo non ha controller. Ancora una volta, è facile immaginare questa visione senza un controller.
Pensa a un controller senza vista, ad es. Qualcuno bloccato in un armadio con il radiocomando sintonizzato sulla frequenza del robot. Questo controller sta inviando input e causando transizioni di stato senza alcuna idea di cosa stanno facendo al modello (se non altro). Facile da immaginare, ma non molto utile senza una sorta di feedback dalla vista.
La maggior parte delle interfacce utente intuitive coordina la vista con il controller per fornire un'interfaccia utente più intuitiva. Ad esempio, immagina una vista / controller con un touch-screen che mostri la posizione corrente del robot in 2-D e consenta all'utente di toccare il punto sullo schermo che si trova proprio di fronte al robot. Il controller ha bisogno di dettagli sulla vista, ad es. La posizione e la scala del viewport e la posizione in pixel del punto toccato rispetto alla posizione in pixel del robot sullo schermo) per interpretarlo correttamente (a differenza del ragazzo bloccato nell'armadio con il radiocomando).
Ho già risposto alla tua domanda? :-)
Il controller è tutto ciò che accetta input dall'utente che viene utilizzato per causare lo stato di transizione del modello. Cerca di mantenere una vista e un controller separati, ma renditi conto che sono spesso interdipendenti l'uno dall'altro, quindi va bene se il confine tra loro è sfocato, cioè avere la vista e il controller come pacchetti separati potrebbe non essere così separato come si farebbe come, ma va bene. Potrebbe essere necessario accettare che il controller non verrà separato in modo chiaro dalla vista poiché la vista proviene dal modello.
... è necessario eseguire una convalida ecc. nel controller? In tal caso, come posso restituire i messaggi di errore alla vista, che dovrebbe ripassare il modello o il controller deve semplicemente inviarlo di nuovo alla vista?
Se la convalida viene eseguita nella vista, cosa inserisco nel controller?
Dico che una vista collegata e un controller dovrebbero interagire liberamente senza passare attraverso il modello. Il controller accetta l'input dell'utente e dovrebbe eseguire la convalida (magari utilizzando le informazioni del modello e / o della vista), ma se la convalida fallisce, il controller dovrebbe essere in grado di aggiornare direttamente la vista correlata (ad es. Messaggio di errore).
Il test dell'acido per questo è di chiederti se una vista indipendente (cioè il ragazzo nell'altra stanza che guarda la posizione del robot attraverso la rete) dovrebbe vedere qualcosa a causa dell'errore di convalida di qualcun altro (ad esempio il ragazzo nell'armadio ha cercato di dire al robot di scendere dal campo). Generalmente, la risposta è no: l'errore di convalida ha impedito la transizione di stato. Se non vi è stato stato di stato (il robot non si è mosso), non è necessario dire le altre opinioni. Il ragazzo nell'armadio non ha ricevuto alcun feedback sul fatto che ha cercato di causare una transizione illegale (nessuna vista - interfaccia utente errata), e nessun altro deve saperlo.
Se il ragazzo con il touchscreen ha provato a mandare il robot fuori dal campo, ha ricevuto un messaggio di facile utilizzo che gli chiedeva di non uccidere il robot mandandolo fuori dal campo di rilevamento, ma ancora, nessun altro deve saperlo.
Se altre viste non c'è da sapere su questi errori, allora si sta effettivamente dicendo che gli input da parte dell'utente e gli eventuali errori risultanti sono parte del modello e il tutto è un po 'più complicato ...