Struttura del progetto MVC 3

Question

Sto cercando di trovare il modo migliore per layout il mio progetto MVC 3. Durante la ricerca online mi sono imbattuto in un suggerimento che in sostanza ha detto clic destro sul progetto e aggiungi l'area. Ciò che questo ha fatto è stato creare una cartella di area con lo stesso controller/vista/struttura del modello nello stesso progetto. Questo non è quello che voglio. Voglio la flessibilità di avere progetti separati. Manterrò solo le visualizzazioni nel progetto Web principale. Tutto il resto in un progetto separato.

Verso quel tentativo ho creato un progetto separato per i miei controller. Ora sono bloccato nel puntare un'azione controller in una vista. In tutti gli esempi online era clic destro e aggiungi la vista. Essendo un progetto di biblioteca di classe non ho questa flessibilità. Dove sto sbagliando?

Tutti gli esempi che ho trovato tra cui quelli che ho passato Asp.net Fondamentalmente spiega come creare applicazioni di studio, il che è buono solo per scopi di apprendimento. Una grande applicazione commerciale non può avere tutte le viste/modelli/controller in un progetto. O è il modo in cui dovrebbe andare in MVC? Non sono sicuro che anche fare tutto con i clic del mouse sia una buona idea. Nel mondo dei WebForms c'erano anche molte applicazioni di studio per mouse che utilizzavano i clic del mouse per creare applicazioni CRUD di base, ma in progetti commerciali reali non abbiamo mai usato questi metodi.

Quali sono i tuoi pensieri, guida su questo?

Grazie per il tuo tempo...

Answer 1

MVC si basa su una convenzione; La convenzione è che si metti tutte le viste /viste, i modelli /modelli e i controller /controller. Puoi cambiare la convention ma non ti semplificherà la vita.

Da un punto di vista concettuale questo ha senso. Se mantieni tutta la logica del dominio e l'accesso ai dati in progetti separati, tutto ciò che ti rimane è il materiale Web, i controller, i modelli di visualizzazione e le viste. Questo è il tuo progetto MVC.

Si noti che se si desidera dividere le parti in progetti separati potresti trovare aree portatili utile.

Answer 2

Non vedo perché non puoi usare i generatori integrati come base per le tue viste e i controller? Niente dice che devi lasciarli come generati. Personalmente penso che sia davvero bello ottenere una base generata per me (con clic del mouse).

Il progetto MVC è solo un livello dell'interfaccia utente. È follia inserire la logica per applicazioni su larga scala. Di solito va bene avere un progetto per tutta l'interfaccia utente. In realtà rende più facile ottenere una panoramica dell'interfaccia utente.

Detto questo, ci sono modi per ottenere una soluzione basata su plug -in in cui è possibile spostare i controller (modelli e viste) nelle librerie di classe. Ma non è facile.

1. È necessario creare un fornitore di percorsi virtuali (per trovare le viste)
2. Fai incorporare tutte le viste
3. Modifica il file di progetto per ottenere la finestra di dialogo "Aggiungi vista" ecc.
4. Usa le aree (lo rende più semplice)
5. Dì la BuildManager che esiste il tuo plugin DLL.

È inoltre necessario modificare il provider del percorso virtuale per accedere alle viste dalle cartelle del plug -in se si desidera essere in grado di modificare le viste durante il runtime in Visual Studio. Qualsiasi modifica richiederebbe altrimenti una ricostruzione della DLL plugin.

Aggiornare

Il video per MVC2 (le aree MVC3 funziona allo stesso modo): http://www.asp.net/mvc/videos/mvc-2/how-do-i/aspnet-mvc-2-areas

Si noti che quel video è per le aree nello stesso progetto. Avere aree in librerie di classe separate è più complesso. La soluzione più semplice è utilizzare le aree portatili come suggerito da qualcun altro.

Answer 3

Perché mantenere solo le tue opinioni nel "progetto Web principale" - Penso che ti manchi il punto con MVC.

Sono i controller che sono la tua parte "Web principale". Sono ciò che i tuoi utenti richiedono e pubblicano, non la vista.

La vista è lì solo per fornire un mezzo per layout HTML affinché il controller si spinga al browser.

I modelli che penso dovrebbero davvero essere ViewModels, sono lì per fornire sostanza (cioè dati reali) per le tue opinioni.

Quindi puoi vedere che il layout MVC vuole davvero che tutti e tre questi siano raggruppati in modo sensato insieme. I controller interagiscono con il tuo utente, ottieni la vista (il layout) e popola con il tuo ViewModel/Model (i dati). Questa è la tua interfaccia utente, tutte e tre le parti di MVC (se si accede comunque a ViewModel) sono solo per l'interfaccia utente.

Da dove provengono i dati, i tuoi modelli reali e qualunque cosa tu voglia fare con esso possono facilmente risiedere in una DLL da qualche parte o dall'altra parte di una serie di servizi web o altro.