MVC: spesso il controllore delega semplicemente a Model quando viene notificato da View of GUI events. È ragionevole?

Question

MVC: spesso il controllore delega semplicemente a Model quando viene notificato da View of GUI events. È ragionevole?

#1 da (1 voti)
#2 da (0 voti)

2

Da quando ho imparato a conoscere MVC, l'ho usato per ogni app che ho fatto (che probabilmente non è l'idea migliore, ma non è l'argomento di questa domanda). Tutte piccole, 1000 app LoC. Sto usando Java e Swing per la GUI.

Ciò che di solito accade è questo:

La vista (la classe della GUI) riporta al controller qualsiasi evento della GUI (più comunemente un clic del pulsante) eseguito. Ad esempio quando viene premuto un pulsante, la vista chiama semplicemente controller.someButtonPressed() o controller.someOtherButtonPressed() . È solo una reazione all'input dell'utente che sta segnalando al controller, nient'altro.

Questo, penso, va bene ed è l'implementazione corretta di MVC View. La parte su cui ho dei dubbi è la seguente:

Nei metodi someButtonPressed() del controller, molto spesso semplicemente delega al modello.

Ad esempio:

public void someButtonPressed(){
    model.doTheAppropriateThing();
}

Niente di più. Nessun "processo decisionale" o "interpretazione" effettiva di ciò che la vista ha riferito. Molto spesso, solo una semplice delega al modello.

È considerato ragionevole quando si implementano le strutture MVC e in particolare i controller, per avere il controller spesso semplicemente delegato direttamente al modello in reazione agli eventi della GUI? Oppure questo segnale che forse sto facendo qualcosa non va?

object-oriented design mvc

posta Aviv Cohn 03.05.2014 - 19:20

fonte

2 risposte

Leggi altre domande sui tag object-oriented design mvc

Problema di progettazione del sistema di gestione dell'inventario "Pacchetti di articoli" Dividere e nascondere le intestazioni in una libreria statica

score 1 · Answer 1

In un mondo ideale, il codice del tuo modello sarebbe in un file DLL / Shared Library / Jar / re-utilizzabile e potrebbe essere incluso in un sistema che gestisce le richieste API da qualsiasi client, che si tratti di un'app Android parlando un protocollo a livello di socket o una pagina web che parla HTTP o qualche strana combinazione di qualcos'altro.

In questi casi, IMHO, il Controller è responsabile di trasformare i dati che appartengono alla View (l'app, la pagina web) opportunamente trasformati per la vista, ma si occupa anche della gestione degli errori (i codici di stato HTTP forse in uno caso, e alcuni formati personalizzati in un altro caso).

In sostanza i controll mediano tra modelli e viste , il che significa che potrebbero aver bisogno di logica che si occupi di tale mediazione (trasformazione dei dati, creazione di DTO, informazione di errore restituita nel modo appropriato). Ma la logica di ciò che significa nel sistema quando un utente prende qualche azione, è la responsabilità del modello. Il modello è la rappresentazione agnostica di view-and-controller del dominio. Il controller media tra.

score 0 · Answer 2

Penso che vada bene se nel tuo esempio hai metodi come someButtonPressed() . Tuttavia, è importante cambiare il controler, ma non il modello se le logiche quando si preme someButton cambia in futuro. Anche il contrario: se il metodo doTheAppropriateThing() dei modelli cambia, non devi preoccuparti della vista.

Il risultato è che la tua vista e il tuo modello sono disaccoppiati e quando il controller sta "passando" solo le chiamate di metodo va bene.