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):
- Classi di modelli.
- Classi di controller (logica del livello aziendale).
- 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.