Devo includere dipendenze per le quali ho l'origine come progetti nella mia soluzione?

Question

Devo includere dipendenze per le quali ho l'origine come progetti nella mia soluzione?

#1 da (4 voti)
#2 da (2 voti)
#3 da (1 voti)
#4 da (0 voti)

5

Abbiamo diversi progetti nel controllo del codice sorgente per applicazioni web e desktop. Invariabilmente, molti di loro usano progetti open source di terze parti o anche librerie comuni all'interno della nostra organizzazione come dipendenze.

Dovremmo includere i progetti completi di queste dipendenze nelle nostre varie soluzioni? O dovremmo semplicemente includere il riferimento .dll (o l'equivalente binario compilato) e mantenere l'origine per detta dipendenza altrove (ad esempio, solo a scopo di debug)?

In particolare sto pensando a progetti e soluzioni .NET in Visual Studio, ma sentitevi libero di sostituire questi termini con JAR o qualsiasi altro equivalente in altri linguaggi e framework.

Per specificare ulteriormente, ti sto chiedendo se una struttura di una finca di app Web per fatture [fittizie] dovrebbe assomigliare a questa:

InvoicePaymentsWeb
InvoicePaymentsDataModel
InvoicePaymentsServices
RickSoftUltraDataGrid
MyCompanyCommonWebLib

E potresti compilare individualmente (o modificare) le varie dipendenze poiché esistono interamente nella tua soluzione. Al contrario di avere solo i primi tre progetti, fare riferimento alle DLL compilate degli altri due e avere l'origine per gli altri due presenti altrove sulla tua macchina (o altrove nel controllo del codice sorgente).

Mi chiedo se questo non possa potenzialmente fratturare lo sviluppo e / o la manutenzione delle varie dipendenze poiché ogni soluzione potrebbe avere le sue specifiche modifiche alla sorgente, a meno che il controllo sorgente sottostante gestisse la condivisione interna dei progetti. Quali altri problemi potrebbero esistere? Ci sarebbe qualche vantaggio?

development-process programming-practices projects-and-solutions project-structure

posta Sean Hanley 17.04.2012 - 16:24

fonte

4 risposte

Leggi altre domande sui tag development-process programming-practices projects-and-solutions project-structure

Quali sono i termini chiave rvalue e lvalue? Passa all'oggetto composto per i parametri

score 4 · Answer 1

Il mantenimento di fonti esterne non aggiunge davvero molto valore. Se usi una particolare versione della libreria, dovrebbe essere sufficiente se hai detto binario nel tuo repository. Tuttavia , se apporterai modifiche alla libreria (senza renderla attiva / pubblica - diciamo che è necessario aggiungere qualcosa di specifico alla tua azienda), allora ha senso avere sorgenti modificate come parte del codice base (in effetti, dovresti memorizzarli da qualche parte). In tal caso, tali sorgenti dovrebbero essere al massimo livello, proprio come la directory delle tue librerie:

Invoices
    Invoices.DataAccess
    Invoices.Reports.Templates
    Invoices.View
    Libraries
    LibrariesSources
    ...

Ovviamente, i binari compilati della libreria modificata andrebbero nella directory Librerie e saranno referenziati da lì (al contrario di mantenerli in grado di dire LibrariesSources\ComplexMath\bin\Release ).

score 2 · Answer 2

Ho sempre una cartella "Dependance" che ha semplicemente tutte le DLL.

Non è necessario disporre della fonte completa di librerie di terze parti a meno che non si preveda di modificare il codice in qualche modo specifico per le proprie esigenze.

Modifica: e dovrebbe essere nel controllo del codice sorgente!

score 1 · Answer 3

Ecco alcuni consigli pragmatici tratti da una solida esperienza: non includere interi progetti.

Questo perché IDE come Visual Studio o Eclipse (specialmente Visual Studio) tendono ad esibirsi davvero male quando vengono caricati con sempre più progetti e codice sorgente da compilare o indicizzare.

Ti conviene includere solo le DLL dove ti servono.

Per motivi di debug, puoi sempre conservare il codice per la libreria da qualche parte , quindi aprirlo come progetto / soluzione indipendente e collegare il debugger al processo che usa quella libreria.

- Modifica

Alcune persone hanno detto che potrebbe essere una buona idea se si intende modificare quelle librerie di terze parti. Non sono d'accordo. Non è necessario includerli nelle altre soluzioni per farlo. Basta modificarli nella propria soluzione e aggiungere nuovamente la versione più recente.

score 0 · Answer 4

Il codice sorgente è utile solo quando è necessario modificare qualcosa sulla libreria di terze parti. Mantenere i binari sul controllo sorgente è meglio che avere l'intero codice sorgente, ma usando strumenti come nuget. Net and mavem per java è molto meglio, perché può risolvere l'intero albero delle dipendenze quando è necessario aggiornare i file binari.