Soluzione .NET: molti progetti e un solo progetto

Question

Attualmente abbiamo un codice C# in rapida crescita. Attualmente abbiamo circa 10 progetti, suddivisi nelle solite categorie, common/util stuff, network layer, database, componenti ui/controlli, ecc.

Ci imbattiamo nella dipendenza circolare occasionale in cui il progetto x dipende da qualcosa in y vice versa. Stiamo forse cercando di ridurre i progetti a uno solo e di gestirli usando cartelle di strutture/spazi dei nomi. Abbiamo un progetto Java che ovviamente organizza solo l'utilizzo di cartelle/pacchetti, quindi non siamo sicuri di quali vantaggi, se del caso, possano portare più progetti. Nessuno dei nostri progetti richiede proprietà di progetto speciali, ad eccezione del progetto di corsa principale, che possiamo tenere separati (e molto sottili).

Qualcuno ha una precedente esperienza sul motivo per cui un progetto è migliore/peggiore rispetto a più progetti e potrebbe suggerire l'approccio migliore? E anche qualsiasi problema con le dipendenze circolari sarebbe utile in entrambi gli approcci sarebbe utile.

Qualsiasi input apprezzato.

Answer 1

Nella mia esperienza, separando il codice che crea un singolo eseguibile in multipla progetti può essere utile se si desidera

• utilizzare diversi linguaggi di programmazione in diverse parti,
• sviluppare le librerie che sono utilizzato anche da altre applicazioni, oppure
• concettualmente separati da più livelli (ovvero lasciare che Visual Studio assicuri che non ci siano riferimenti diretti dal progetto Lib a progetto App).

Personalmente, ho basato la maggior parte delle mie decisioni sul secondo punto.Penso che parte dell'applicazione possa essere una libreria più generale di cui probabilmente ho bisogno in altre applicazioni? Mettilo in un progetto separato. Altrimenti, come fai notare, avere un singolo progetto di solito rende più facile lo sviluppo.

Circa le dipendenze circolari: Il metodo consigliato per risolvere questo è quello di mettere interfacce delle cose si fa riferimento in un terzo progetto. Ad esempio, se si hanno due applicazioni che condividono alcuni oggetti tramite il servizio remoto, si mettono le interfacce degli oggetti condivisi in un progetto di libreria per assicurarsi che siano disponibili per entrambe le applicazioni.

Senza conoscere il disegno esatto della vostra applicazione, è difficile dare consigli più concreto.

Answer 2

Se si dispone di progetti con dipendenze circolari, ciò indica un problema con la progettazione del codice, non con la soluzione/modello di progetto.

Answer 3

Più progetti consente un migliore riutilizzo di tipi specifici all'interno di più applicazioni. Può anche migliorare i tempi di costruzione, poiché alcuni progetti non dovranno essere ricostruiti per tutte le modifiche al codice.

Un singolo progetto semplifica la vita, dal momento che non devi preoccuparti delle dipendenze. Basta rendersi conto che la facilità ha un costo - rende anche più facile lasciare che le decisioni di progettazione scadenti si insinuino nel codice base. Le dipendenze circolari, in un progetto o in più, sono in genere un difetto di progettazione, non un requisito.

Answer 4

Quando si effettuano le dipendenze tra i progetti, aiuta a pensare sempre di uno come "inferiore" e l'altro come

Un progetto di livello "Higher" più alto (ad esempio un'interfaccia web) dovrebbe dipendere solo su progetti più bassi. Un progetto inferiore (come un'utilità) non dovrebbe mai dipendere da qualcosa di più elevato, come un'interfaccia web. Se questo accade, significa che il tuo progetto di livello più alto ha qualcosa che dovrebbe davvero essere nel progetto inferiore, o viceversa.

Answer 5

Inizia con un singolo progetto. L'unico vantaggio nel dividere il tuo codebase in più progetti è semplicemente quello di migliorare i tempi di costruzione.

Quando ho alcune funzionalità riutilizzabili che desidero veramente isolare dal progetto principale, inizierò appena una nuova soluzione per questo.

Answer 6

Abbiamo notato che le prestazioni di Visual Studio degrada in modo significativo il numero di progetti cresce. Qualcosa di semplice come passare dalle configurazioni "Debug" a "Release" può richiedere fino a 15 secondi per soluzioni con circa una dozzina di progetti C# in esse.

Inoltre, come un punto di contrasto con il commento di Reed su tempi di costruzione, ho visto costruire volte crescono perché Visual Studio sembra essere spendere un sacco di tempo sulle spese generali del progetto. I tempi di compilazione effettivi sembrano rapidi, ma il tempo totale di colpire la build per essere in grado di eseguire è significativo.

Il mio consiglio è di tenere il numero di progetti al minimo si può farla franca. Se hai bisogno di più progetti per buone ragioni, usali se necessario, ma preferisci mantenere le cose insieme. Puoi anche fare il refactoring per dividere un progetto in due se necessario.

Answer 7

Ci sono molte ragioni per separare una soluzione in diversi progetti (e quindi assemblee), e si tratta principalmente verso re-usabilit y e separazione delle responsabilità.

Ora il tuo obiettivo dovrebbe essere quello di fare in modo che un assembly (ovvero un progetto) abbia la minima quantità di dipendenze da altri assembly nella tua soluzione, altrimenti potresti avere tutto in un minor numero di assiemi. Se, ad esempio, i componenti dell'interfaccia utente hanno una forte dipendenza dal codice di accesso ai dati, allora c'è probabilmente qualcosa di sbagliato.

Davvero, questo si riduce a programmazione contro interfacce comuni.

Nota Tuttavia:

quando dico "altrimenti si può anche avere tutto in un minor numero di assemblee", non ero necessariamente suggerendo questa è la cosa sbagliata da fare. Per ottenere una vera separazione delle preoccupazioni, scriverai molto più codice e dovrai pensare al tuo design molto di più. Tutto questo lavoro extra potrebbe non essere molto utile per te, quindi pensaci attentamente.

Answer 8

In generale, avere più progetti VS (all'interno di una soluzione VS) si limita a dare un senso in questi casi

• Si può potenzialmente riutilizzare la DLL prodotta in un altro progetto (una libreria di classi)
• Volete a separare le cose come in un'architettura a strati in cui si può cadere la dll DAO e scambiarlo con un altro
• ci sono solo diversi progetti di front-end (ad esempio applicazioni ASP.net MVC) che devono essere distribuito in diversi luoghi fisici, ma l'uso lo stesso BL, DAL.

Se stai dicendo che stai avendo il problema delle dipendenze circolari, allora stai avendo un problema nella progettazione del codice. Probabilmente potresti mettere quella logica che è usata da più progetti all'interno di una libreria di classi progettata per essere riutilizzata in molti progetti.

In generale, direi che non dovresti aggiungere altri progetti se non ne hai davvero bisogno. Divisione in progetti significa aggiungere più complessità, quindi quando lo fai, dovresti trarne un ragionevole vantaggio.

Answer 9

È possibile trovare il seguente articolo di Martin utile: Design Principles and Design Patterns (PDF)(Java).

Una versione rivista in C# è disponibile in Principi agili, schemi e procedure in C# anche da Martin.

Entrambi esprimono linee guida diverse che ti aiuteranno a decidere cosa appartiene. Come sottolineato, tuttavia, le dipendenze cicliche indicano che ci sono problemi di progettazione o che qualcosa si trova in un componente che appartiene a uno diverso.

Answer 10

Dove lavoro, abbiamo optato per un approccio in cui lo scopo è avere un singolo progetto per soluzione. Tutti i progetti di libreria di codici hanno anche un'applicazione di test harness e/o un'app unit test.

Fintantoché le librerie di codice superano il test, le versioni di rilascio (con il file di documentazione Xml ovviamente) vengono trasferite in una cartella "In diretta".

Qualsiasi progetto che richiede funzionalità da questi altri progetti deve fare riferimento alla cartella "In diretta".

I vantaggi sono abbastanza chiari. Qualsiasi progetto accede sempre al codice di lavoro conosciuto. Non c'è mai la possibilità di referenziare un'assemblea di lavori in corso. Il codice viene testato per assemblaggio, rendendo molto più facile capire da dove proviene un errore. Le soluzioni più piccole sono più facili da gestire.

Spero che questo aiuti!

Shad