Devo incluir dependências para as quais tenho a origem como projetos na minha solução?

5

Temos vários projetos em controle de origem para aplicativos da Web e de desktop. Invariavelmente, muitos deles usam projetos de código aberto de terceiros ou até mesmo bibliotecas comuns em nossa organização como dependências.

Devemos incluir os projetos completos dessas dependências em nossas várias soluções? Ou deveríamos apenas incluir a referência .dll (ou binário compilado equivalente) e manter a fonte da dita dependência em outro lugar (digamos, apenas para propósitos de depuração)?

Estou pensando especificamente em projetos e soluções .NET no Visual Studio, mas sinta-se à vontade para substituir esses termos por JAR ou qualquer equivalente em outros idiomas e estruturas.

Para especificar ainda mais, estou perguntando se uma árvore de soluções [ficcional] de fatura da Web de pagamentos da fatura deve ficar assim:

  • InvoicePaymentsWeb
  • InvoicePaymentsDataModel
  • InvoicePaymentsServices
  • RickSoftUltraDataGrid
  • MyCompanyCommonWebLib

E você pode individualmente compilar (ou alterar) as várias dependências, uma vez que elas existem inteiramente dentro de sua solução. Ao contrário de apenas ter os três primeiros projetos, referenciar as DLLs compiladas dos outros dois, e ter a fonte para os outros dois, existe em outro lugar em sua máquina (ou em outro lugar no controle de origem).

Gostaria de saber se isso não prejudicaria o desenvolvimento e / ou a manutenção de várias dependências, já que cada solução poderia ter suas próprias alterações específicas na origem, a menos que o controle de origem subjacente manipulasse o compartilhamento dos projetos internamente. Quais outros problemas podem existir? Haveria algum benefício?

    
por Sean Hanley 17.04.2012 / 16:24
fonte

4 respostas

4

A manutenção de fontes externas não agrega muito valor. Se você usa uma versão particular da biblioteca, deve ser o suficiente se você tiver dito binary em seu repositório. No entanto, , se você fizer alguma alteração na biblioteca (sem torná-lo ativo / público - digamos que você precise adicionar algo específico à sua empresa), faça sentido modificar fontes como parte do código base (na verdade, você deve armazená-los em algum lugar). Se for esse o caso, essas fontes devem estar no nível superior, assim como o diretório de bibliotecas é:

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

Naturalmente, os binários compilados da biblioteca alterada iriam para o diretório Bibliotecas e serão referenciados a partir dali (ao invés de mantê-los em LibrariesSources\ComplexMath\bin\Release ).

    
por 17.04.2012 / 16:41
fonte
2

Eu sempre tenho uma pasta "Dependancies" que simplesmente tem todas as DLLs.

Não há necessidade de ter a fonte completa de bibliotecas de terceiros, a menos que você planeje modificar o código de alguma forma específica para suas necessidades.

Editar: e deve estar no controle de origem!

    
por 17.04.2012 / 18:10
fonte
1

Aqui estão alguns conselhos pragmáticos de experiências difíceis: não inclua projetos inteiros.

Isso porque os IDEs como o Visual Studio ou o Eclipse (especialmente o Visual Studio) tendem a ter um desempenho muito ruim quando carregados com mais e mais projetos e código-fonte para compilar ou indexar.

É melhor você apenas incluir as DLLs onde precisar delas.

Para fins de depuração, você sempre pode manter o código da biblioteca em algum lugar e depois apenas abri-lo como um projeto / solução independente e anexar o depurador ao processo que a utiliza.

- Editar

Algumas pessoas mencionaram que pode ser uma boa ideia se você pretende modificar essas bibliotecas de terceiros. Discordo. Você não precisa incluí-los em suas outras soluções para fazer isso. Basta editá-los em sua própria solução e adicionar novamente a versão mais recente.

    
por 17.04.2012 / 22:11
fonte
0

O código-fonte é útil somente quando você precisa modificar algo na biblioteca de terceiros. Manter os binários no controle de origem é melhor do que ter todo o código-fonte, mas usando ferramentas como o nuget para. Net e mavem para java é muito melhor, porque pode resolver toda a árvore de dependências quando você precisa atualizar os binários.

    
por 17.04.2012 / 19:32
fonte