Buone pratiche sulle soluzioni di Visual Studio [chiuso]

Speriamo che una semplice domanda di relatività. Sto iniziando a lavorare su un nuovo progetto interno per creare la tracciabilità dei dispositivi riparati all'interno degli edifici.

Il database è archiviato in remoto su un server Web e sarà accessibile tramite API Web (output JSON) e protetto con OAuth. La GUI del front-end viene eseguita in WPF e il codice aziendale in C #.

Da questo, vedo i diversi livelli Presentazione / Applicazione / Archivio dati. Ci sarà codice per la gestione di tutte le chiamate autenticate all'API, classe per rappresentare entità (oggetti business), classi per costruire entità (oggetti business), parti per la GUI di WPF, parti dei modelli di WPF e così via.

È meglio crearlo in un singolo progetto o dividerlo in singoli progetti?

Nel mio cuore dico che dovrebbero essere più progetti. L'ho fatto in entrambi i modi in precedenza e ho scoperto che i test sono più facili con una soluzione a singolo progetto, tuttavia con più progetti possono sorgere dipendenze ricorsive. Soprattutto quando le classi hanno interfacce per rendere più semplice il test, ho scoperto che le cose possono diventare imbarazzanti.

Dipende dalle dimensioni del progetto

Ecco le linee guida che tendo a usare

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

• Se il livello di accesso ai dati del piccolo progetto è grande o complesso, potrei separarlo nel suo livello, ma per il resto 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 confini tra le funzionalità dell'applicazione.

• Se l'applicazione ha molteplici scopi, ognuno con le proprie viste, modelli di visualizzazione, ecc., Di solito separerò ogni pezzo nella propria area. Se ogni sezione è piccola, li separo da una cartella. Se ogni sezione è grande, li separerò da un progetto.

• Se ho più progetti che hanno bisogno di fare riferimento lo stesso insieme di oggetti ( ViewModelBase, RelayCommand, ecc), creerò un progetto solo per gli oggetti di infrastruttura condivisi.

• 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, poiché la manutenzione diventa un incubo :)

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

Non cadere nella trappola dell'utilizzo di progetti in cui desideri veramente lo spazio dei nomi. 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 passare più spesso. Raramente collegherai una GUI a più livelli di dati e ti aspetti che funzioni bene. Lo scenario molto più comune è che si dispone di un singolo livello dati e si desidera che sia distribuito su più GUI (ad esempio ASP.Net, WPF e un'app Silverlight). È fantastico quando puoi semplicemente creare il progetto del livello dati e inserire quella dll come riferimento nella prossima GUI che crei.

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 si contano i test unitari

Ho sempre usato un'unica soluzione se lavoro su quei diversi strati o se c'è uno stretto accoppiamento con essi. 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 separato 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 al punto in cui le cose non sono così complesse che i cambiamenti in una parte dell'app spezzano le cose in parti apparentemente non correlate dell'app.

Risolve quando sto facendo una sorta di inversione di dipendenza, per mettere tutti i "contratti", interfacce, classi astratte, oggetti di trasferimento dati in un unico assieme. In un altro assembly ho inserito tutto ciò che parla al database. I test unitari ottengono il loro assemblaggio. Se l'interfaccia utente è fondamentalmente non verificabile (ad esempio Winforms ASP.NET), allora vi è un vantaggio significativo nel dividere l'interfaccia utente in codice verificabile e codice non verificabile, 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 avrei voluto fosse nel framework .NET. Quel codice lo inserirò in un assembly di utility, o almeno lo inserirò in qualunque sia l'assembly root (probabilmente quello con le interfacce.

Se tutti gli assiemi fanno riferimento a tutti gli assiemi, o quasi, dovrebbero essere riuniti in un unico assieme. Se tu o le persone del tuo team non avete la disciplina per evitare di inserire il codice del livello dati nell'interfaccia utente e nell'interfaccia utente nel livello dati, quindi semplificate le cose unendo nuovamente tutto in un unico livello.

Alcune edizioni di Visual Studio incontrano problemi di prestazioni in circa 15 assembly, a volte dipende dal tipo di progetto presente. Tuttavia, a volte può essere utile scaricare file di progetto strategicamente.

L'unico buon motivo per avere più di un progetto è se è necessario condividere un set di classi e file su più applicazioni.

Se i progetti sono utilizzati da una sola applicazione, non avrebbero dovuto essere realizzati in primo luogo. Utilizzare invece gli spazi dei nomi. Salva te stesso il problema dei riferimenti circolari, delle spese generali della DLL e della confusione del progetto quando cerchi i file.

Leggi questo articolo per una spiegazione migliore e più approfondita del perché: http://lostechies.com/chadmyers/2008/07/16/project-anti-pattern-many-projects-in-a-visual-studio- soluzione a file /

E come afferma l'articolo, darei il benvenuto a chiunque abbia un motivo valido per avere più progetti oltre alla condivisione del codice attraverso l'applicazione per dirmi di cosa si tratta, perché dubito che ce ne sia.