Struttura del progetto ASP.net MVC

Question

Ho creato la seguente struttura di progetto per il mio nuovo progetto asp.net mvc, dopo aver ricevuto alcuni feedback su come altre persone stanno strutturando i loro progetti e se potessi migliorare i miei...

Ecco cosa ho finora:

+Assets
-+Images 
-+Scripts 
-+Stylesheets 
-+...              'More things like the above here
+Controllers 
-+Support
--+Actions         'Any custom action classes
--+Controllers     'Base controller classes
+Models
-+Domain           'Contains any class that specialise view specific domain logic
--+UrlProcessing   'Encoding/decoding business entities as URL parts 
--+...             'More things like the above here
-+Views            'Contains view models
--+Support
---+Views          'Base classes for any view models
+Support
-+Application      'Global application interface classes (i.e. class that wraps the function of the global asax)
-+Configuration    'Typed config classes
-+Helpers          'Where you put additional html helper classes, etc
-+Services
--+Bootstrap       'Tasks that run on mvc start-up that are specific to the MVC project
--+Inversion       'Specific IoC registration registrations for this project 
--+...             'More things like the above here
+Views
-+Home
-+Shared 
-+...              'More things like the above here

Saluti Antonio

Answer 1

Ho struttura simile della vostra con alcune eccezioni:

  

  
1. Supporto prende il nome Infrastructure (spazio dei nomi per l'utilizzo di assemblaggio UI solo)
  
2. IoC è diverso progetto (progetto per la funzionalità Infrastruttura usato globalmente). UI ha StructureMaps Registro solo con nomi di assemblaggio (CIO viene inizializzato per convenzione). Approccio genere un rubato da fonte CodeCampServer. Registrazione, sezioni di configurazione va anche qui.
  
3. Vista / [NomeControllore] ha sottocartella parziale che potrebbe essere ancora più diviso
     (Si tratta di giocoleria con ViewEngine in modo che possa trovare views / vista parziale).
  cartella
4. Vista / [NomeControllore] ha LocalResources (con sottocartella parziale)
  
5. non hanno (ancora ...) aggiunto alcun sottocartella Controllers. Mi piace tenerli puliti e abbastanza stupido.
  

E alcune più eccezioni, legate con il modello:

  

  
1. Tutta la logica di business vive in assemblea dominio, spazio dei nomi Domain.Model con qualche aiuto dello strato Infrastruttura per gli aspetti tecnici.
  
2. Visualizza i modelli (sto chiamandoli Viewdata) vive in assemblea utente nella cartella Viewdata, strutturato in cartelle simili a quelle viste sono. Scelto approccio da Kigg (tranne che i strutturarli per View come SearchViewData, a volte anche per view parziale).
  

E funziona abbastanza bene finora

Si noti che la strutturazione Viewdata (ho anche strutturare la mia javascript allo stesso modo, Vista file di == JS che contiene tutto sotto oggetto denominato come [ViewName]) per view potrebbe non essere accettabile per il più complicato web siti.

Oh ... e => cartella == spazio dei nomi per me. Direi che è una buona pratica.

Answer 2

Sito MVC
applicazione - tutti i file statici
--comune
----css
------styles-most-pages-use.css
----img
------immagini-la-maggior-pagina-use.png
----js
------your-custom-lib.js
--File
----release_notes.md
----release_notes.html
--pagine
----registrazione
------signin.css
------logo.png
------signin.js
----pannello di controllo
------dashboard.js
--venditori
----jquery
------jquery.1.11.1.js
-_references.js

Controller - solo controller sottili, solo codice per chiamare le funzioni della libreria principale
Modelli - solo i modelli utilizzati per visualizzare la vista
Visualizzazioni - solo codice client come html, rasoio, css, ecc

Biblioteca principale
Fondamentalmente tutto il codice...accesso ai dati, attributi personalizzati, utilità, ecc.Separare il codice principale in una sola libreria è utile per molte ragioni.La tua logica ora non è legata solo a un sito web.Se ho bisogno di creare un front -end rapido in Winforms per testare alcune logiche o potrei utilizzare le stesse funzioni nel livello di accesso ai dati per creare un front -end di amministrazione per il database.

Trovo che questa struttura sia per me la più semplice e flessibile.

Aggiornamento
Ho aggiornato la struttura dei file di contenuto statico per renderla più flessibile e moderna.Ho ideato questa struttura lavorando con AngularJS.Alla fine sono passato a... RactiveJS.Dopo essere passato a RactiveJS, la stessa struttura ha funzionato davvero bene.

Aggiornamento 21-8-15Ultimamente ho lavorato su progetti più grandi e ho separato la libreria Core nel proprio progetto Visual Studio.Ciò lo rende flessibile quando si utilizzano SVN esterni.Posso utilizzare la stessa libreria su diversi progetti e devo solo eseguire un aggiornamento SVN per ottenere le modifiche.Inoltre è stato implementato anche il sito MVC nel proprio progetto.

Answer 3

Ho scritto un paio di (piccoli) siti e semplicemente bloccato con la stessa struttura che NerdDinner aveva e tutto sembrava funzionare bene.

Credo che su progetti più piccoli che è un approccio bene finché avete la vostra separazione delle preoccupazioni, non collocare la logica di business nel repository (s), ecc La tentazione di un progetto più piccolo è di confondere le linee, ma MVC tende punirti un po 'quando fai così. :)

progetti più grandi possono vedervi l'attuazione di un progetto separato business class e forse anche progetto di traduzione dei dati, ecc.

Answer 4

Credo che questo sia un po 'troppo complicata, ma se ha senso si va con esso. La cosa importante è quello di mantenere l'equilibrio.

Una cosa che mi piace andare con progetti separati all'interno della soluzione in quanto consente per il riutilizzo di accesso ai dati e Business Logic per essere riutilizzati da altri tipi di applicazioni client, come WPF o WinForms clienti.