Come strutturare più soluzioni / progetti sovrapposti in .Net?

Question

Come strutturare più soluzioni / progetti sovrapposti in .Net?

#1 da (9 voti)
#2 da (5 voti)

16

Recentemente ho iniziato a lavorare per un nuovo client con una base di codice vecchia legacy in cui ci sono più soluzioni .net, ognuna di solito ospita alcuni progetti unici per tale soluzione ma poi "prende in prestito" / "link" in "(aggiungi progetto esistente) altri progetti che tecnicamente appartengono ad altre soluzioni (almeno se vai dalla struttura di cartelle in TFS)

Non ho mai visto un setup così intrecciato, non esiste un chiaro ordine di build, a volte un progetto in soluzione A si riferiscono alle DLL direttamente dalla directory di output di un progetto ospitato nella soluzione B, a volte il progetto è stato incluso direttamente anche se risiede lontano nella struttura della cartella.

Sembra che tutto sia stato ottimizzato per la pigrizia degli sviluppatori.

Quando li ho confrontati con il motivo per cui non avevano un server CI hanno risposto che è difficile da configurare con il codice organizzato come è. (Lo sto configurando ora e maledico questa organizzazione del codice)

Le soluzioni sono organizzate attorno a artefatti di distribuzione (cose che devono essere distribuite insieme sono nella stessa soluzione) che I think è una decisione saggia, ma i contenuti di tali soluzioni (i progetti) sono dappertutto.

Esiste un consenso su una best practice da utilizzare quando si riutilizzano le librerie di classi comuni tra più soluzioni / risorse di distribuzione,

Come strutturare il codice nel VCS
Come facilitare la condivisione della logica di business tra gli artefatti di distribuzione separati

version-control projects-and-solutions code-organization deployment

posta AndreasKnudsen 19.08.2011 - 14:12

fonte

2 risposte

Leggi altre domande sui tag version-control projects-and-solutions code-organization deployment

Gli sviluppatori bloccati aspettando che il codice si unisca da un altro ramo usando GitFlow Come adottare una metodologia agile per lo sviluppo di firmware / sistemi embedded-software?

score 9 · Answer 1

Non sono mai stato un fan di includere progetti esistenti che appartengono ad altre soluzioni. Ci sono troppe variabili in cui apportare una modifica a quel progetto per 1 soluzione rompe completamente qualcosa in un'altra soluzione. Quindi risolvendo il problema si finisce per rompere la soluzione originale. Mescolare, sciacquare, ripetere.

Quando questo tipo di dipendenza si diffonde in più soluzioni, mi piace separare il codice dipendente nella sua soluzione PROPRIA e creare una libreria black-box che viene quindi inclusa come riferimento. Il mio pensiero è che le vostre soluzioni fossero intrecciate in modo tale che il debug potesse essere fatto fino in fondo nel progetto condiviso per ogni soluzione. Se la libreria è costruita e testata correttamente, questo tipo di debug non è davvero necessario. La biblioteca dovrebbe essere in grado di sostenere i propri meriti e dovrebbe essere testata a fondo in modo tale da soddisfare le aspettative di qualsiasi progetto di consumo in modo coerente.

score 5 · Answer 2

In realtà ho organizzato tali strutture TFS come quella che stai citando e, sebbene presenti sfide uniche per l'IC, ha una serie di benefici diversi. Uno chiaro è che supporta e incoraggia la corretta componentizzazione in progetti .NET separati e quindi supporta il buon TDD incoraggiando il 100% di copertura del test. A prima vista ho notato alcuni problemi che puoi risolvere.

sometimes a project in solution A just reference dlls directly from the output directory of a project hosted in solution B, sometimes the project has just been included directly even if it resides FAR away in the folder structure.

I riferimenti binari all'output di altre directory non sono un buon approccio e diventano un cattivo approccio se mescolati con riferimenti di progetto. Prova a fare l'uno o l'altro, preferibilmente modificando i riferimenti binari in riferimento ai riferimenti ai progetti per ottenere la coerenza. A questo punto ogni soluzione può rappresentare una singola applicazione o livello di applicazione costruibile, (ad esempio SuperApp.sln, OtherAppServices.sln, OtherAppPresentationTier.sln).

Per costruire TUTTI i progetti, ti consiglio anche di creare una Master Solution. La soluzione master avrà riferimenti di progetto a tutto ed essenzialmente esiste per il solo vantaggio di avere un singolo comando di build che gestisce tutti i progetti nella suite di applicazioni. Gli sviluppatori non dovrebbero usare la Master Solution per lo sviluppo attivo o il debugging. Questo rende l'assemblaggio degli artefatti di costruzione molto più semplice.

La distribuzione può quindi essere eseguita con un semplice batch, PowerShell o script Perl. Ciò essenzialmente creerà la soluzione appropriata o la soluzione Master e quindi distribuirà tutto negli ambienti appropriati. Questo può essere facilmente integrato in qualsiasi server CI se fatto bene.

•How to facilitate sharing of business logic between separate deployment artifacts

Crea un progetto per una logica aziendale comune o separa meglio le preoccupazioni per una logica di business più globale o universale. Tutte le soluzioni dispiegabili che desiderano fare riferimento a questo dovrebbero farlo con un riferimento al progetto.

Nell'organizzare il tuo codice in TFS, diventa più facile ottenere ciò mantenendo progetti comuni o condivisi ad un livello più alto nell'albero delle directory.