Best practice per l'architettura MVC [chiuso]

Chiuso . Questa domanda deve essere più focalizzata . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che si concentri su un problema solo modificando questo post .

Chiuso 4 anni fa .

La mia domanda è più su come progettare un'applicazione MVC. Ad esempio, siamo incoraggiati a utilizzare DI con il modello Repository per disaccoppiare l'accesso ai dati dal controller, anche se su HOW si fa ben poco per farlo specificatamente per MVC. Dove inseriremmo le classi del repository, per esempio? Non sembrano essere specificamente legati al modello, poiché il modello dovrebbe anche essere relativamente disaccoppiato dalle attuali tecnologie di accesso ai dati.

Una seconda domanda riguarda come strutturare i livelli o i livelli. La maggior parte delle applicazioni di esempio (cena per nerd, negozio di musica, ecc.) Sembrano tutte utilizzare un approccio a 2 livelli a livello singolo (senza contare i test) che in genere ha controller che chiamano direttamente il codice L2S o EF.

Se voglio creare un'applicazione multilivello / layer quali sono alcune delle migliori pratiche in materia di MVC?

asp.net-mvc architecture

— Erik Funkenbusch
fonte

Risposte:

DI viene realizzato in ASP MVC utilizzando una Controller Factory. Questa fabbrica viene utilizzata per risolvere le dipendenze del controller.

MvcContrib ha alcune implementazioni di Controller Facotry che puoi usare immediatamente. Uso l'implementazione di Castle Windsor e funziona bene. Suggerirei anche di verificare la loro classe TestHelper. Ha alcune funzionalità molto interessanti per deridere Controller HTTPContext, Sessioni, ecc. MVCContrib

Personalmente mi piace dare ai miei modelli un'istanza di repository con cui lavorare. Il modello espone un'API al repository (CRUD). La dipendenza del controller da un particolare modello viene iniettata nella creazione (costruttore), che viene iniettata tramite Controller Factory. Questo è il mio punto di accesso al grafico a oggetti gestito dal mio contenitore IoC.

Dove inseriremmo le classi del repository, per esempio?

Appartengono al modello; sono il modello in-application.

Come strutturare i livelli? Se voglio creare un'applicazione multilivello / layer quali sono alcune delle migliori pratiche in materia di MVC?

I livelli rappresentano le separazioni fisiche del codice. I livelli rappresentano separazioni logiche. I livelli (così come sono attualmente) funzionano bene per MVC. A seconda della quantità di logica aziendale, può essere collocato nel proprio controller oppure può essere inserito in un assembly separato e può essere utilizzato dal controller durante il ciclo di richiesta.

— George Stocker
fonte

Quindi stai suggerendo che dovrebbero andare nel Progetto UI di un'applicazione multi-tier?

— Erik Funkenbusch,

@Mystere Man Se non è gigantesco, dovrebbero andare nel progetto che ospita l'applicazione MVC. In particolare, la logica aziendale andrebbe nel controller e ogni azione avrebbe la propria logica. MVC non è solo un modello dell'interfaccia utente; ecco perché non sono d'accordo con la tua affermazione che si tratta di un "progetto UI". Non lo è. È un progetto MVC che come Viewsezione (c'è la tua UI).

— George Stocker,

Ok, forse l'ho espresso male. Tuttavia, non sei d'accordo sul fatto che il livello di visualizzazione non dovrebbe manipolare il database? E se si inseriscono le classi Repository nel modello, la vista può farlo.

— Erik Funkenbusch,

in un'applicazione Small MVC, l'interfaccia utente "Layer" è semplicemente la cartella che contiene le viste. In un'applicazione più grande, potrebbe essere il suo progetto. Se si tratta del proprio progetto, si coordinerebbe con il controller e il controller potrebbe agganciarsi al BusinessLayer secondo necessità. Nessuno al di fuori del controller avrebbe nemmeno bisogno di sapere che esisteva il livello aziendale. Penso che stai automaticamente pensando che questi siano in progetti separati, ma non devono esserlo.

— George Stocker,