Relazione tra progetti e soluzioni in VS

Naviga le tue risposte
2

Stiamo per iniziare con un nuovo software e ci sono opinioni contrastanti sull'organizzazione del software. Sarei lieto di ascoltare ciò che gli altri potrebbero avere da dire riguardo alle opzioni presentate e su quale altra considerazione si possa fare quando si prende una simile decisione.

  1. Approccio gerarchico
  2. Approccio intercambiabile

L'approccio n.1 consisterebbe in un'unica soluzione in VS con un numero di progetti ad essa collegati (come Utilità , Servizio , Esportatore , Gui ecc.). Tutto sarebbe in una singola raccolta e nella stessa directory radice (per il file della soluzione) e nelle sottodirectory (per i file di progetto), per così dire.

L'approccio n. 2 sarebbe costituito principalmente da un insieme di progetti, non correlati tra loro (diversi dai riferimenti, ovviamente), mentre le soluzioni (o le soluzioni ', vorremmo creare configurazioni diverse per consegne diverse) scopo sarebbe esclusivamente di fare riferimento ai progetti (esterni) che li raccolgono nella GUI. Ci sarebbero n + 1 directory (una per ogni file del progetto e una aggiuntiva per il file della soluzione, o i file delle soluzioni in seguito).

Abbiamo discusso la questione e elencato i vantaggi di ciascun approccio e, sebbene concordati sui fatti, i membri del team non sono sulla stessa pagina per quanto riguarda quale scegliere. Siamo un'organizzazione molto democratica, quindi la decisione deve essere persuasiva per tutti (o almeno una grande maggioranza) e non ci sarà alcun ordine da parte del capo. Non esiste una base di codice precedente e la considerazione finanziaria non deve essere affrontata.

Quale approccio è preferibile? Qual è più uno standard comunemente applicato nel settore? Quali considerazioni si potrebbero fare per garantire la rigidità della scelta?

È anche possibile che il nostro attuale progetto sia soggetto alla situazione descritta in questa domanda - sia quello che" prende in prestito "progetti da altrove sia quello da cui i progetti sono" presi in prestito ".

    
posta Konrad Viltersten 23.07.2014 - 09:53
fonte

2 risposte

6

Dipende ... è tutto basato sulla gestione delle dipendenze.

Avrai molto più facile tempo con una singola soluzione. In questo modo puoi semplicemente fare riferimento agli altri progetti all'interno di un progetto e tutto verrà creato e aggiornato ogni volta. Questo approccio non scala però.

Quindi il problema dipende interamente da quei fastidiosi riferimenti. Il problema più grande che ho riscontrato è che i percorsi verso riferimenti esterni (cioè non parte della soluzione) erano relativi. Quindi i membri del tuo team devono eseguire il checkout di una libreria nella stessa posizione nell'albero di compilazione così come è stata creata in origine. Se puoi vivere con questa restrizione, la costruzione di singoli progetti sarà fattibile.

Tuttavia, oggi Microsoft sta usando NuGet come un modo per consegnare le librerie alle applicazioni. Costruisci una lib, la impacchetta come NuGet e la distribuisci su un server. Quindi, quando un'applicazione vuole usare questa libreria, la preleva automaticamente. Non più compilando, puoi sempre ottenere l'ultima versione dal server di build (hai così CI, se no - ottieni Jenkins. OSS / gratuito e fantastico)

Questo significa che puoi concentrarti sulla tua parte dell'applicazione piuttosto che sulle dipendenze. Significa anche che avrai maggiori probabilità di mantenere una buona separazione delle preoccupazioni in queste librerie.

    
risposta data 23.07.2014 - 10:16
fonte
1

Raccomando un approccio a soluzione singola, specialmente per l'inizio di un nuovo progetto. (Puoi diventare più complicato in seguito, se necessario.)

La stessa MS deve dire al riguardo:

La mia esperienza è (come dice MS):

This structure simplifies development because all of the code is available when you open the solution. This strategy also makes it easy to set up references, because all references are between projects in your solution.

E

You should use this structure if all developers use the same solution and have the same set of projects. This could be a problem for large systems where you want to organize projects by sub-system or feature.

I progetti multi-soluzione sono un mal di testa (credetemi io am ci atm.) e dovresti farlo solo se hai bisogno , perché i componenti sono molto accoppiato liberamente e deve essere in grado di essere compilato e combinato in modo isolato o perché hai così tanti progetti (direi che > 100 è una stima approssimativa ) che una singola soluzione diventa ingombrante.

Nota: saltando il saggio su NuGet / gestori di pacchetti / il tuo SCC e CI specifici. Interpretano tutto questo.

    
risposta data 28.04.2016 - 10:38
fonte

Leggi altre domande sui tag

Quando una Monade diventa un martello? Esiste un modo migliore per caricare gli oggetti?