Cartelle o progetti in una soluzione Visual Studio?[Chiuso]

Question

Quando si suddivide una soluzione in livelli logici, quando è meglio utilizzare un progetto separato anziché raggrupparlo semplicemente in base a una cartella?

Answer 1

Per impostazione predefinita, crea sempre e solo una nuova cartella all'interno dello stesso progetto

• Riceverai un assemblaggio singolo (senza ginnastica ILMerge aggiuntiva)
• Più facile da offuscare (perché avrai meno tipi e metodi pubblici, idealmente nessuno)

Separare il codice sorgente in più progetti ha senso solo se...

• Avere alcune parti del codice sorgente che fanno parte del progetto ma non distribuibili per impostazione predefinita o del tutto (test unitari, plug-in extra ecc.)
• Più sviluppatori sono coinvolti e vuoi trattare il loro lavoro come una scatola nera consumabile.(non molto consigliato)
• Se puoi separare chiaramente il tuo progetto in livelli/moduli isolati e vuoi assicurarti che non possano essere utilizzati in modo incrociato interno membri.(anche sconsigliato perché dovrai decidere quale aspetto è il più importante)

Se ritieni che alcune parti del tuo codice sorgente possano essere riutilizzabili, non crearlo comunque come un nuovo progetto.Aspetta solo finché non vorrai davvero riutilizzarlo in un'altra soluzione e isolarlo dal progetto originale secondo necessità.La programmazione non è un LEGO, il riutilizzo è solitamente molto difficile e spesso non avviene come previsto.

Answer 2

La separazione delle funzionalità in progetti è spesso un'ottimizzazione dell'architettura YAGNI.Quanto spesso hai riutilizzato quei progetti separati, davvero?Se non si tratta di un evento frequente, stai complicando lo sviluppo, la creazione, la distribuzione e la manutenzione per un riutilizzo teorico.

Preferisco di gran lunga la separazione in cartelle (utilizzando gli spazi dei nomi appropriati) e il refactoring per separare i progetti quando si ha un caso d'uso di riutilizzo nella vita reale.

Answer 3

denny ha scritto:

Personalmente ritengo che se il codice riutilizzabile è suddiviso in progetti è più semplice utilizzare altri posti rispetto a quando si trova solo nelle cartelle.

Sono davvero d'accordo con questo: se puoi riutilizzarlo, dovrebbe essere in un progetto separato.Detto questo, è anche molto difficile riutilizzarlo in modo efficace :)

Qui a SO, abbiamo cercato di essere molto semplici con tre progetti:

• Progetto Web MVC (che fa un buon lavoro nel separare i livelli in cartelle per impostazione predefinita)
• Progetto database per il controllo del codice sorgente del nostro DB
• Test unitari rispetto a modelli/controller MVC

Non posso parlare per tutti, ma sono contento di quanto abbiamo mantenuto la semplicità: velocizza davvero le build!

Answer 4

Di solito realizzo un progetto per la GUI, un progetto per la logica aziendale, un progetto per l'accesso ai dati e un progetto per i test unitari.

Ma a volte è prudente avere una separazione basata sui servizi (se si utilizza un'architettura orientata ai servizi) come autenticazione, vendite, ecc.

Immagino che la regola pratica su cui lavoro sia che se riesci a vederlo come un componente che ha una chiara separazione delle preoccupazioni, allora un progetto diverso potrebbe essere prudente.Ma penso che le cartelle rispetto ai progetti potrebbero essere solo una preferenza o una filosofia.

Personalmente ritengo che se il codice riutilizzabile è suddiviso in progetti è più semplice utilizzare altri posti rispetto a quando si trova solo nelle cartelle.

Answer 5

Separare il codice sorgente in più progetti ha senso solo se ......Più sviluppatori coinvolti e vuoi trattare il loro lavoro come scatola nera consumabile.(non molto consigliato) ...

Perché non è consigliato?L'ho trovato un modo molto utile per gestire un'applicazione con diversi sviluppatori che lavorano su porzioni diverse.Rende i check-in molto più semplici, soprattutto eliminando virtualmente le fusioni.Molto raramente due sviluppatori dovranno lavorare sullo stesso progetto contemporaneamente.

Answer 6

Se crei diversi progetti, assicurati che tutti coloro che aggiungono codice alla soluzione siano pienamente consapevoli delle loro intenzioni e fai tutto il possibile per convincerli a comprendere le dipendenze tra i progetti.Se hai mai provato a risolvere il pasticcio quando qualcuno è andato e ha aggiunto riferimenti che non avrebbero dovuto essere lì e se n'è andato per settimane, capirai questo punto

Answer 7

Penso davvero che sia meglio anche dividere il progetto, ma tutto dipende dalle dimensioni del progetto e dal numero di persone che ci lavorano.

Per progetti più grandi, ho un progetto per

• accesso ai dati (modelli)
• Servizi
• fine frontale
• test

Ho preso il modello da Rob Connery e la sua domanda in negozio...sembra funzionare davvero bene

mvc-negozio