Buone pratiche su Visual Studio Solutions [chiuso]

Dipende dalla dimensione del progetto

Ecco le linee guida che tendo a usare

• Un piccolo progetto, con una manciata di pagine o meno, mi limito quasi sempre a un singolo progetto.

• Se il livello di accesso ai dati del piccolo progetto è grande o complesso, potrei separarlo nel suo stesso livello, ma altrimenti si trova nella sua cartella.

• Se il progetto è più grande, avrò quasi sempre un progetto separato per il DAL e ogni ulteriore suddivisione dipende da dove si trovano i limiti tra le funzionalità dell'applicazione.

• Se l'applicazione ha più scopi, ognuno con le sue viste, i suoi modelli di visualizzazione, ecc., di solito separerò ogni pezzo nella sua area. Se ogni sezione è piccola, le separo da una cartella. Se ogni sezione è grande, le separerò da un progetto.

• Se ho più progetti che devono fare riferimento allo stesso insieme di oggetti ( ViewModelBase , RelayCommand , ecc.), creerò un progetto solo per gli oggetti dell'infrastruttura condivisa.

• Se ho una grande quantità di stili / modelli / risorse personalizzati condivisi, creerò un progetto solo per quelli.

Come nota a margine, ho commesso un errore con il mio primo grande progetto WPF e li ho separati inserendo Modelli in un progetto, Viste in un altro e ViewModels in un terzo. Ora posso dirti che non è la strada da percorrere, dal momento che la manutenzione diventa un incubo:)

Ho visto i migliori risultati con un progetto per strato, oltre a un progetto di test per livello. Ho visto poche applicazioni che non possono essere realizzate in 10 o meno progetti nella soluzione, dove la soluzione comprende tutto .

Non cadere nella trappola dell'uso di progetti in cui si desidera veramente il namespacing. Tonnellate di progetti non aggiungono altro che spese generali senza alcun guadagno.

L'IMHO separato è quasi sempre migliore. Quasi sempre separo il mio livello dati a meno che il progetto non sia banale al 100%. Il motivo è perché il livello dati tende a essere trasmesso il più spesso possibile. Raramente collegherete una GUI a più livelli di dati e aspettate che funzioni bene. Lo scenario molto più comune è che si dispone di un singolo livello dati e si desidera che venga distribuito su più GUI (ASP.Net, WPF e un'app Silverlight, ad esempio). È fantastico quando puoi creare il progetto del livello dati e inserire la dll come riferimento nella prossima GUI che hai creato.

Per me, 4 * è il numero magico. Un progetto per ogni livello e un progetto che definisce tutte le interfacce / DTO necessarie per comunicare tra loro.

* 7 se conti i test unitari

Ho sempre usato un'unica soluzione se sto lavorando su questi diversi livelli, o se c'è un accoppiamento stretto con loro. Voglio colpire F5 e far ricostruire tutti i progetti se necessario. Non penso che ci sia un modo "giusto" per farlo.

Il suo gusto personale, la cosa più importante è essere coerenti . Personalmente ho un progetto seprate per ogni livello dell'applicazione, quindi la separazione è ovvia.

L'aumento del numero di progetti ha a che fare con l'abilitazione dei test unitari e la semplificazione del grafico delle dipendenze fino al punto in cui le cose non sono così complesse che le modifiche in una parte dell'app rompono le cose in parti apparentemente non correlate dell'app. / p>

Funziona quando eseguo una sorta di inversione di dipendenza, per mettere tutti i "contratti", le interfacce, le classi astratte, gli oggetti di trasferimento dati in un unico assieme. In un'altra assemblea metto tutto ciò che parla al database. I test unitari ottengono il proprio assemblaggio. Se l'interfaccia utente è fondamentalmente non testabile (ad es. Winform ASP.NET), allora c'è un vantaggio significativo nel dividere l'interfaccia utente in codice verificabile e codice non testabile, un assembly ciascuno. A volte inizia a comparire del codice che non ha nulla a che fare con il database, l'interfaccia utente o qualsiasi altra cosa che ho menzionato finora - è il codice che desideravo fosse nel framework .NET. Quel codice inserirò in un assembly di utilità, o almeno lo inserirò in qualunque assembly root (probabilmente quello con le interfacce.

Se tutti gli assembly fanno riferimento a tutti gli assembly o quasi, devono essere uniti in un unico assembly. Se tu o le persone del tuo team manchi la disciplina per evitare di inserire il codice del livello dati nell'interfaccia utente e nell'interfaccia utente nel livello dati, quindi semplificare le cose unendole tutte in un unico livello.

Alcune edizioni di Visual Studio vengono eseguite in problemi di prestazioni in circa 15 assiemi, a volte dipende dal tipo di progetto esistente. Tuttavia, a volte è possibile aiutare a scaricare i file di progetto in modo strategico.

L'unica buona ragione per avere più di un progetto è se è necessario condividere un insieme di classi e file su più applicazioni.

Se i progetti vengono utilizzati da una sola applicazione, non dovrebbero essere stati creati in primo luogo. Utilizza invece gli spazi dei nomi. Salva te stesso il problema dei riferimenti circolari, del sovraccarico della DLL e della confusione del progetto quando cerchi i file.

Leggi questo articolo per una spiegazione più approfondita del perché è così: link

E come dice l'articolo, sarei felice di ricevere chiunque abbia una ragione valida per avere più progetti oltre alla condivisione del codice attraverso l'applicazione per dirmi di cosa si tratta, perché dubito che ce ne siano.