MVC: il mio controller sembra inutile metà del tempo. È un problema?

8

Spesso quando progetto un programma con MVC, il controller è inutile metà del tempo.

Ciò che intendo è questo: qualcosa accade nella vista (ad esempio un clic del pulsante). La vista quindi notifica al controller. Il controller quindi delega direttamente al modello e non fa nient'altro perché non ha nulla da fare.

Ad esempio:

L'utente preme il pulsante "Colore blu" > vista dice controller controller.colorBlue() > controller dice al modello model.colorBlue() > il modello colora qualcosa di blu.

In questo esempio, il controller sembra inutile. Non aggiunge nulla. La vista potrebbe anche aver parlato direttamente con il modello.

L'altra metà del tempo, tuttavia, il del controllore fa una sorta di mediazione tra la vista e il modello.

La mia domanda è questa: quanto è comune questo nelle strutture MVC? È ragionevole che metà del tempo il mio controllore sembra non necessario? O questo è un problema? È comune? Come dovrei avvicinarmi a questo?

Se la mia domanda non è abbastanza chiara, la prego di dirlo.

    
posta Aviv Cohn 07.05.2014 - 22:58
fonte

2 risposte

12

Stai sottovalutando l'importanza di avere uno strato di astrazione tra la tua interfaccia utente e il tuo modello. Il controller svolge questa funzione il 100 percento delle volte.

Il tuo esempio model.colorBlue() è un po 'specioso. In un modello reale, questo sarebbe probabilmente un metodo CRUD. Quindi il tuo pulsante potrebbe essere un pulsante Crea cliente, il tuo metodo controller sarebbe CreateCustomer() e il tuo modello sarebbe CreateCustomer() . Certo, stai solo passando per la chiamata.

E se fosse necessario cambiare il modo in cui il modello funziona? Se la tua vista stava chiamando direttamente il tuo modello, l'applicazione si interromperà se cambi il modello. I metodi del controller forniscono un "punto di accesso" per la tua vista; puoi apportare una semplice modifica al metodo del controller, magari modificando la chiamata del modello a CreateCustomerWithVerification() , e tutto funziona ancora.

Lo stesso ragionamento vale per avere un livello di servizio. Invece di avere semplicemente metodi CRUD nel tuo modello, dovresti avere delle azioni commerciali. In tal modo, mantieni la logica aziendale fuori dai tuoi controllori e rendi possibile utilizzare il Modello da qualche altra parte, magari in un'applicazione WPF.

Pensa al Controller come a un "Cortile". Dovrebbe essere un intermediario tra le richieste di mediazione tra l'interfaccia utente e il modello, ma i metodi del controller dovrebbero avere il minimo di logica possibile.

    
risposta data 07.05.2014 - 23:08
fonte
-1

Durante la codifica potresti pensare in questo modo:

  • Sarò in grado di cambiare la visualizzazione con qualcos'altro (console, servizio) o lo stesso controller per una vista diversa?
  • Sarò in grado di cambiare modello per gestire database diversi o scrivere su qualche servizio esterno?

Nel tuo caso sembra che stai mettendo la logica del dominio in modello e questo ti causerebbe problemi se vuoi cambiarlo: dovrai copiare metodi come "model.colorBlue" sul nuovo modello.

E cosa accadrebbe se la definizione di "blu" cambia? Dovrai cambiarlo 2 modelli. Inoltre nel controller non dovresti scrivere direttamente nel tuo database, ma come indicava Lie Ryan dovresti usare model.setColor .

Uguale alle visualizzazioni. Se si avvia la visualizzazione della logica o della convalida, se si desidera modificare la vista sarà necessario copiare tutte le funzionalità.

    
risposta data 08.05.2014 - 10:17
fonte

Leggi altre domande sui tag