Cosa è meglio, molti piccoli assiemi o un grande assieme?

Tutto è nel titolo :)Cosa è meglio, molti piccoli assiemi o un grande assieme?

Attualmente, abbiamo una soluzione VS2005 con 20+ projets. Mi piace

MySolution 
MySolution.Modules.Foo 
MySolution.Modules.Bar 
[insert many here] 
MySolution.Modules.Baz

Può esserci un danno per "unire" MySolution.Modules. * In un progetto? Tutti gli spazi dei nomi saranno conservati, quindi nessun problema qui.

Ma c'è qualcosa a cui non ho pensato?

Nota: attualmente non ci possono essere riferimenti circolari: se MySolution.Modules.Foo fa riferimento a MySolution.Modules.Bar, MySolution.Modules.Bar non può fare riferimento a MySolution.Modules.Foo. Quindi dovremo stare attenti a non crearne.

fonte

2009-02-20 mathieu

Sono stato in un paio di aziende dove troppi progetti sono stati un dolore in vari modi. Non sono ancora stato in nessun posto che abbia avuto anche pochi progetti, anche se questo è certamente possibile.

Pensa a un progetto come a un'unità di riutilizzo, tra le altre cose. Qualunque prodotto avrà bisogno di Foo ma non di Bar, o viceversa? In caso contrario, unirli insieme.

Mi piace tenere separati i diversi livelli (presentazione, business logic, accesso ai dati) ed è bello disporre di una libreria di utilità comune, indipendente dal prodotto, ma in molti casi è la stessa cosa.

Oh, e prove di tenere in un progetto diverso per il tuo codice di produzione, ovviamente :)

fonte

2009-02-20 08:56:38

D'altra parte Domain Driven design è l'ispirazione per la divisione verticale del codice. – Slampen

@Slampen: non ho abbastanza esperienza di DDD da dire. –

Penso che il dolore che soffri con molti piccoli progetti sia nascosto se tutti sono in un unico grande blob. – Slampen

vantaggi di un complesso:

potenzialmente Potenza
potenzialmente più facile implementazione

Vantaggi di molti assembly:

Tutto il resto. Supponendo che questi siano buoni moduli coesivi, aiuta a separare le preoccupazioni, a controllare le dipendenze costringendoti a pensare al livellamento/stratificazione della tua architettura, ecc.

fonte

2009-02-20 08:55:43 Brian

Non avere molti piccoli assemblee rallenta le prestazioni dello studio visivo? E ogni singolo assembly non ha un sovraccarico in esso durante la creazione dei simboli di metadati e di debug? –

@MeyerDenney vedi http://stackoverflow.com/a/1218220/59996 – Aligma

tempo di compilazione. Se hai il tuo progetto rotto in pezzi, solo il pezzo che è stato modificato deve essere compilato. Se fa tutto parte di un grande progetto, dovrai ricompilare ogni volta che cambi qualcosa. A seconda di quanto è grande il tuo progetto, questo può essere un grosso problema.

fonte

2009-02-20 08:59:09

Non ho mai visto questo essere un grosso problema per i progetti C#. Al contrario, il sovraccarico di MSBuild sembra a volte più pesante del compilatore C#. (Si tratta di prove completamente aneddotiche). –

Per prima cosa, Visual Studio inizia a richiedere sempre più tempo per caricare la soluzione se si dispone di tonnellate di progetti, al contrario di alcuni progetti con tonnellate di codice al loro interno.

Questa non è necessariamente una buona ragione per avere un solo progetto, sopra tutti gli altri menzionati qui, ma qualcosa da tenere a mente.

fonte

2009-02-20 08:59:57

L'ho già sentito, ma non l'ho mai provato. Puoi definire "tonnellate"? Ho una soluzione con> 50 progetti e carica come un fulmine. –

Potrebbero esserci altri fattori coinvolti. Stiamo utilizzando TFS e potrebbe trascorrere del tempo aggiornando lo stato del controllo del codice sorgente, ma la nostra soluzione contiene 45 progetti e può consumare 30 secondi buoni per caricarsi nel peggiore dei casi. Certo, non molto, ma i test dimostrano che questo è legato al numero di progetti. –

@Kent, ci sono stato e ho sentito il dolore – johnc

Usiamo ILMerge per legare tutti i nostri piccoli assemblaggi in un blocco più grande. Soprattutto assemblaggi che si trovano in progetti diversi ma che alla fine fanno parte dello stesso spazio dei nomi.

Ad esempio, abbiamo molte entità di dati per record e viste distribuite su un numero di assiemi, MJ.DE.views.dll, MJ.DE.tables.dll, MJ.DE.sprocs.dll ecc. Ma alla fine usiamo ILMerge per metterli insieme in un singolo MJ.DE.DLL. - rende più facile l'aggiornamento/la sincronizzazione dell'app, dal momento che con il server di produzione ci sono meno cose e sappiamo che tutte le classi correlate provengono dalla stessa compilazione.

fonte

2009-07-28 05:34:53 MikeJ

Cosa è meglio, molti piccoli assiemi o un grande assieme?

risposta

Problemi correlati