Recursos para estrutura concepção .dll

Question

Eu só saiu de uma reunião de design e tinha uma pergunta feita a mim sobre onde eu tenho uma das minhas idéias sobre como estruturar algumas .dlls de um projeto que estamos construindo. Para ser honesto eu não tenho nenhuma idéia de onde esta "ideia" veio, pareceu conhecimento natural para mim. No entanto, seria útil se eu poderia fazer backup desses pareceres com alguma análise documentada.

Alguém sabe de quaisquer recursos que explicitamente discutir mecanismos diferentes para os conjuntos de estruturação / modules / fonte?

UPDATE:

Bem, a idéia era nada de especial. Nós estávamos discutindo uma camada de abstração para algum hardware de modo que o "app" que consome estes serviços poderia ser (tipo de) independente de plataforma. Anteriormente tivemos um interfaces de .dll que declara as interfaces do aplicativo requer e uma .dll implementação que implementa-los para a plataforma que nós tivemos até agora. Agora temos duas plataformas, mas eles são muito semelhantes. Para evitar que as interfaces .dll de ser poluído ou algum cenário horroroso onde as implementações de referência um ao outro Eu simplesmente sugeriu que criar outro .dll que fica entre as interfaces e specificplatform.dlls onde implementações abstratas comuns podem viver.

Answer 1

Se você tiver uma chance, dê uma olhada no livro de Robert C. Martin:

princípios ágeis, padrões, e Práticas em C # (Esta é a nova versão especificamente alvejado para Net)

Há um capítulo dedicado ao design componente que (provavelmente) responde a sua pergunta.

Em resumo, e depois de ler esse livro, eu sempre recomendo componentes separando por estes critérios:

• Assembléias são unidades ou reutilização :. Se existem classes que têm de ser utilizados em conjunto, vão no mesmo assembly

• Assembléias são unidades de alteração :. Se existem classes que não têm a mudança, pela mesma razão, eles provavelmente não deveria estar na mesma montagem

• Assembléias são unidades de implantação :. Se existem classes que têm de ser fisicamente implantados no mesmo lugar, eles provavelmente deve ir no mesmo assembly

Claro que estas são apenas heurísticas e não receitas. Você eventualmente precisa decidir o quanto de cada um desses três heurísticas de design que você precisa com base nas metas arquitetônicas de sua aplicação (especificamente os objetivos de arquitectura para a implantação e evolução / modificação).