Ho una soluzione per la mia applicazione web con quasi 12 progetti e 3 siti web. Alcuni progetti vengono utilizzati per più siti Web come progetti MyProject.BE/MyProject.BLL/MyProject.DAL/MyProject.Controls.Visual Studio Large Solution
La mia domanda è, è bello avere più progetti per BE/BLL/DAL/Controlli, di è meglio creare 1 progetto con le cartelle per i livelli BE/BLL/DAL?
La domanda di "grande" è una questione relativa. Nello sviluppo del software è principalmente una questione di quanto è buono il tuo PC. Se è possibile compilare ed eseguire 100 progetti in 1 secondo, 100 progetti in una soluzione sono "piccoli". Quindi è davvero una questione di ciò che funziona per te.
La mia attuale soluzione di lavoro contiene circa 130 progetti. Sì, potremmo eliminarlo, ma abbiamo delle scatole impressionanti in grado di gestirlo, quindi il costo di avere 130 progetti è da moderato a basso ei vantaggi sono maggiori dei costi.
Avere tutti i progetti in un'unica soluzione è il go se è possibile compilare, eseguire, & testarli tutti rapidamente. Accidenti ... che poi inizia la conversazione su ciò che è "veloce" e questa è una domanda di stile. Se compili ed esegui i test spesso (ogni minuto o più velocemente), il quick è secondi. Se compili ed esegui ogni ora circa, i minuti andrebbero bene.
Risposta: "Fai quello che funziona per te".
Nota: considerare le cartelle della soluzione.
La mia ultima azienda aveva oltre 350 progetti in un'unica soluzione. La maggior parte dei progetti erano librerie di classi che erano referenziate all'interno di un altro progetto. Sebbene la soluzione avesse 350 progetti, ciò non significa dire che si trattasse di una soluzione di grandi dimensioni. Si trattava di una soluzione di grandi dimensioni a causa della complessità e della quantità di codice di ciascun progetto. Come ha detto Rob Smyth, è tutto relativo. Abbiamo scoperto che costruire l'intera soluzione era pericoloso, quindi abbiamo creato solo i progetti che avevamo. OSSIA abbiamo solo costruito i progetti su cui avevamo apportato delle modifiche. – zeencat
+1 per l'aiuto per capire che cosa potrebbe essere una soluzione "grande", anche +1 per il suggerimento di utilizzo della cartella. – Larry
di "buon PC" stai parlando principalmente di RAM (dimensioni e velocità)? o la velocità di accesso all'HDD è più importante? – mlhDev
Penso che sia davvero meglio avere più progetti. Se, ad esempio, è necessario creare un'interfaccia utente di WinForms che utilizzi alcune delle classi esistenti nei livelli BE e DAL, tutto ciò che devi fare è fare riferimento a quei progetti dal progetto WinForms.
Per quanto ho risposto alla domanda, ci si riferisce a come-organizzare-una-soluzione piuttosto che come fare-fare-compilare-il-codice più velocemente o come fare-VS- open-my-code-quicker, giusto?
In tal caso, direi, suddividere le classi all'interno della soluzione in più progetti con nomi che chiariscano lo scopo che hanno. Hai già iniziato un approccio del genere con l'esempio "BE/BLL/DAL/Controls" che hai dato.
Il progetto designato offre molta flessibilità per l'architettura della soluzione. Pensa a quanto la tua soluzione potrebbe crescere nel tempo e per quanto tempo potrebbe vivere in futuro. Pensa a come lo distribuirai agli utenti finali e, cosa più importante, a come implementerai gli aggiornamenti. Tutte queste considerazioni dovrebbero influenzare la tua decisione quanto lontano andrai nei dettagli.
Analizza il codice e controlla se esiste la possibilità di applicare modelli di progettazione comprovati dal tempo come il modello di Responsabilità singola.
È uno strumento di breve durata a breve termine che viene eseguito alcune volte durante lo sviluppo e mai più? Quindi non varrebbe molto sforzo. È uno strumento o un'applicazione che dovrà essere mantenuta per alcuni anni? Quindi vai e fai causa che il pattern SRP sia implementato con cura.
Consiglio questo libro da Microsoft Press: Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern
Questo vi dà alcuni suggerimenti, consigli e principi fondamentali di come costruire una buona struttura di progetto.
Un altro suggerimento di come una soluzione potrebbe essere strutturata è in questo SO discussione: Mvvm Applications And location of Business layer
Se li si fondono in un unico, come hai intenzione di fare riferimento negli altri, quella attuale sembra bene ma è l'attuale problema/problema? – V4Vendetta
* quasi 12 progetti * - cioè 11 progetti? –
Più progetti va perfettamente bene. Ho lavorato a soluzioni con circa 60 progetti. –