Come mostrare a qualcuno la potenza del modello di progettazione modello-vista-controller?

3

Ho lavorato con un amico a un progetto che abbiamo preso in mano e ho capito che abbiamo un grosso problema nell'implementare il modello di progettazione del modello-vista-controller a causa del modo in cui il progetto è stato configurare.

Il progetto è attualmente suddiviso nelle seguenti tre sezioni (file .proj in Visual Studio):

  1. Classi di modelli.
  2. Classi di controller (logica del livello aziendale).
  3. Visualizza classi.

Visual Studio non mi permette di creare riferimenti ciclici (abbastanza comprensibili) tra due di questi tre sottoprogetti. Ciò significa che le classi controller possono avere una relazione con le classi view, ma le classi view non possono avere una relazione con le classi controller! Il risultato è che non appena il controller visualizza una vista, il resto della logica di controllo deve andare nella classe view!

Quindi ho proposto di unire tutti e tre i sottoprogetti insieme (per evitare i riferimenti ciclici dello studio visivo). Ciò significa che possiamo creare tutte le relazioni tra i tre tipi di classi richieste dal paradigma di progettazione modello-vista-controllore. In definitiva, saremo in grado di posizionare la logica di controllo nel posto giusto dei controllori, portandolo fuori dalle classi di vista.

Il problema è che ho difficoltà a convincere il mio amico a riguardo. Pensa che avere questi confini separati tra i sottoprogetti significa che c'è la sicurezza che non faremo mai cose come mettere il controllo o la visualizzazione del codice nel modello (dato che al sottoprogetto del modello viene sempre fatto riferimento e non lo fa fare riferimento al controller o alla vista).

Mi chiedevo se qualcuno potesse inventare alcuni modi in cui avrei potuto capire cosa fosse importante questo modello di design, e quanto limitarlo sarebbe andare contro di esso, e continuare a mettere la logica del controller nelle classi vista ?

Grazie mille.

    
posta James Bedford 18.04.2011 - 23:00
fonte

3 risposte

4

Il controller in realtà non dovrebbe mantenere la logica aziendale, dovresti provare a mettere più logica possibile nei tuoi modelli, non nel controller.

La vista dovrebbe comunicare solo con il modello, non con il controller.

Il controller imposta il modello (o un ViewModel specializzato, EditModel) e lo passa alla vista.

La preoccupazione principale del controller è la gestione della logica di presentazione, quale schermata viene dopo cosa ecc. Il controller filtra semplicemente, collega tra loro lo schermo ecc.

L'impossibilità di fare riferimento al controller dalle tue visualizzazioni mi sembra salutare. Il modello dovrebbe avere tutto ciò che la vista potrebbe mai avere bisogno. Il controller può avere un ruolo nell'aiutare il modello a raggiungerlo.

    
risposta data 19.04.2011 - 01:27
fonte
2

Il mio suggerimento sarebbe di prendere in considerazione la creazione di interfacce implementate dalla classe view ma la classe controller può usare quell'interfaccia come un modo per sapere cosa contiene la vista. Questo è quello che ho visto dove lavoro che a volte funziona abbastanza bene. Le interfacce sono un progetto separato senza dipendenze poiché sono solo stub delle chiamate anziché un'implementazione reale.

Per quanto riguarda un suggerimento per il tuo amico, considera dove ti piacerebbe mettere i test e come dovrebbero essere strutturati in modo che una modifica dell'interfaccia utente non stia improvvisamente rompendo un gruppo di test unitari se si tratta di un cambiamento puramente per il gusto dell'aspetto ?

Un'altra idea potrebbe essere quella di prendere in considerazione una piccola porzione dell'intero sistema per inserirla in una struttura MVC e vedere quanto bene o non va bene in termini di utilizzo effettivo in quanto è qui che accadrà il grande apprendimento.

    
risposta data 19.04.2011 - 00:17
fonte
1

L'argomento migliore che trovo è dal punto di vista del test.

Se si dispone di una classe controller che gestisce tutta la logica, è possibile testarla facilmente con test unitari di base. Poiché le classi di visualizzazione conterranno solo la creazione di grafica e interfaccia utente, non sarà necessario testarle.

L'altra opzione è che le funzionalità di visualizzazione e controller si trovano nelle stesse classi, il che significa che i test si baseranno sugli eventi dell'interfaccia utente per i test.

Una volta che inizi a pensare dal punto di vista di rendere i test facili, il buon design del codice spesso viene automaticamente.

    
risposta data 19.04.2011 - 00:17
fonte

Leggi altre domande sui tag