Como você estrutura suas bibliotecas reutilizáveis?

Question

Como você organiza seu código para que ele possa ser facilmente portado entre projetos empresariais sem levar inchaço desnecessário?

Por exemplo (em .net), digamos que você tem as seguintes namespaces:

namespace Computers
    - Hardware
         - Motherboard
         - GPU
namespace Monitors
    - Display
         - Mirrors
namespace Peripherals
    - USB
    - PS/2

• Você criar um projeto por namespace pai e, em seguida, fazer referência a essa dll projeto em outros projetos?
• Você criar uma biblioteca de classes grande e porta que coisa ao redor (mesmo se você só precisa de 5% da biblioteca)?
• Ou, você apenas criar um arquivo e copie o código que você precisa para esse arquivo; toting esse arquivo em torno em todos os projetos que você precisa para alcançar um "plug and play" arquitetura (como mau como parece)?

Editar: Eu não estou olhando para .Net responde especificamente, mas é o exemplo concreto que estou usando (desde um exemplo abstrato tornaria mais difícil de entender a questão neste caso)

Answer 1

Você cria um projeto por progenitor espaço de nomes e, em seguida, referência que dll projeto em outros projetos?

Não necessariamente. Ele geralmente acaba dessa forma porque minhas bibliotecas normalmente não são muito grandes, mas você vai notar a Microsoft certamente não faz isso. System.Web existe mesmo se você não incluir a referência System.Web. Você acabou de receber mais classes se o fizer. Indicando que o namespace System.Web é usado em várias DLLs diferentes.

Você criar uma biblioteca de classes grande e porta que coisa ao redor (mesmo se você só precisa de 5% da biblioteca)?

Sim. espaço no disco rígido é barato, mais barato do que manter o código redundante.

Ou, você apenas criar um arquivo e copiar o código que você precisa para esse arquivo; toting que cerca de arquivo em todo o projetos que você precisa para alcançar um "Plug and play" arquitetura (como ruim como este parece)?

Depende da função. Normalmente, eu iria colocar algo assim em um trecho. Por exemplo, uma função típica que aparece em meus projetos web é algo como:

void ShowErrorMessage(HtmlTableRow row, string message)
{
   row.Cells.Clear();
   row.Cells.Add(new HtmlTableCell());
   row.Cells[0].InnerHtml = message;
   row.Cells.Attributes.Add("class", "error");
   row.Visible = true;
}

Nunca parecia ser um bom candidato para uma função de biblioteca porque então eu teria que passar na classe CSS eu queria usar e, ocasionalmente, o valor colspan para a célula. Mas você vai ver algum tipo de aplicação como esta sentado em um poucos lugares em meus projetos web.

Answer 2

Eu levo minha sugestão de DNA, e copiar todo ou partes do meu um enorme biblioteca de classes de projeto para projeto, mesmo se eu usar apenas 1% da biblioteca em qualquer projeto de um. Eu reescrever livremente métodos e classes conforme necessário.

Embora essa abordagem é um pouco contra a sabedoria convencional de programação, eu não iria derrubá-lo: ele tem trabalhado com muito sucesso para coisas vivendo nos últimos 3,5 bilhões de anos. Como na vida, a alternativa (cimentar as interfaces e as implementações por partilha entre conjuntos compilados projectos) inibe a mudança e praticamente garante eventual extinção.

Answer 3

Eu mantenho cada componente como um módulo discreto, e usar Maven para gerir as minhas dependências (não é apenas para Java, consulte este , Byldan é um equivalente Net).

Dessa forma, você pode reutilizar o código sem a necessidade de incluí-lo no projeto. No seu exemplo acima eu poderia ter três artefatos, um para cada namespace a menos que haja uma boa razão para mantê-los juntos (isso ajuda a reforçar o acoplamento fraco).

Answer 4

Eu encontrei recentemente que eu tento manter o número de projectos para baixo, mesmo que apenas para que o número de conjuntos reais criadas no final é reduzido - Acabei de encontrá-lo mais fácil de lidar durante o desenvolvimento. Este é, possivelmente, porque acho que é difícil criar projetos que são verdadeiramente modular e independentes um do outro embora.

Eu acho que a regra geral poderia ser: se o projeto pode realmente ser desenvolvido independentemente de todos os outros e conectado a outros projectos, sem quaisquer outras dependências, em seguida, torná-lo seu próprio projeto. Se você achar que há sempre outros projetos que precisam ser referenciados para que ele ao trabalho (por exemplo, talvez em seus monitores do projeto você achar que nada vai funcionar a menos que você também incluir o namespace Computadores com as classes GPU), então eu colocá-los juntos em um projeto.

Além disso, eu não acho que as regras são muito dura e rápida. Realmente depende muito do que é nas assembleias, é difícil fazer regras arbitrárias ...

Apenas meus dois centavos, não vale muito ...

Answer 5

I começar com uma única dll, e como ele se torna maior e começa a conter alguns componentes bastante independentes, que podem optar por fator-los como dll separado. Para mim, é principalmente uma questão de estética - Eu gosto de manter as coisas independentes e ortogonais e bem organizada. Não há nada de errado com um grande dll, dada a quantidade de memória, espaço em disco disponível hoje em dia.

Answer 6

Para o material que é compartilhado em vários projetos que geralmente acompanham a abordagem grande DLL. Aqui está o problema, porém, se você tem muitos projetos usando esse cara, eu recomendo nomeação forte lo e lançá-lo no GAC. O que você eventualmente vai correr em como você adicionar mais e mais projetos é o desejo de fazer uma mudança quebrar a um componente compartilhado. Se você não estiver usando forte nomeação / GAC, então você tem que ir e atualizar cada aplicativo quando você fazer a mudança, e, inevitavelmente, você vai esquecer um, e algo na produção vai explodir.

nome forte, mantenha uma versão em uma pasta centralizada no controle de origem, e sempre referência a esse. Em seguida, na implantação lançá-lo no GAC.