Muitas DLLs com poucas classes ou poucas DLLs com muitas classes?

Question

Bom dia pessoal,

estou com esta dúvida pois meu sistema fica meio dividido em modulos.
Antes tinha uma dll de telas, um de negócios e uma de dados.
Repensando e desejando ficar menos "preso" achei melhor fazer uma dll pra cada ocasião.
Ficaria assim
UI.Financeiro.Dll
UI.OutraCoisa.Dll

Entidade.Financeiro.Dll
Entidade.OutraCoisa.Dll

Negocios.Financeiro.Dll
Negocios.OutraCoisa.Dll

e assim pra dados e tudo mais.
Para coisas comuns em todos os módulos, criei mais uma dll
Entidade.Comun.dll por exemplo, que vai ter métodos utilizados por todos.

O que acham?
Alguem tem algo a dizer sobre isso?

---

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" (Martin Fowler)

Answer 1

Fala Leandro,

Boa questão. Sempre vai depender do tipo do sistema, mas eu tenho uma linha de pensamento geral:

Eu, anteriormente, costumava fazer esse tipo de separação "sempre que podia", imaginando que fazendo isso conseguiria manter o sistema o mais "flexivel" possível... Na verdade, hoje faço uma avaliação mais detalhada sobre o sistema, e sempre que possível só separo em dll's quando realmente é possível reutilizar esse módulo em outros sistemas.

Me preocupo em separar com cuidado as "camadas" em namespaces bem definidos, de modo que caso surja a necessidade de separar essa camada em uma dll específica, não teremos maiores dificuldades... Na prática bastará criar um outro projeto, mover as classes para o mesmo e referenciá-lo.

Na minha opinião, facilita o gerenciamento do código, build, deploy...

Mais uma vez... Vai depender do sistema...

Forte abraço,

André Borges Medeiros
MCPD, MCT

>> Se a resposta solucionar sua dúvida, favor Votar como Útil

Answer 2

André,

penso que mais tarde posso entregar somente os módulos de cada cliente de forma separada e não um pacote inteiro. Por isso a separação.
Você considera a maneira que decidi correta?

Obrigado

---

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" (Martin Fowler)

Answer 3

Fala Leandro,

Ok. Como eu havia dito, depende muito do sistema.

Se você consegue "enxergar" esse benefício no seu sistema, não vejo porque não fazer.

Uma outra opção, se for o caso, poderia ser:

Financeiro.Dll => Contendo as classes dos namespaces:

UI.Financeiro

Entidade.Financeiro
Negocios.Financeiro

OutraCoisa.Dll => Contendo as classes dos namespaces:

UI.OutraCoisa
Entidade.OutraCoisa
Negocios.OutraCoisa

Dessa forma você manterá as classes correlacionadas "andando" sempre junto. Assim, para entregar o módulo "Financeiro" para o seu cliente basta entregar a Financeiro.dll, ao invés das 3, como no seu modelo.

Além disso, dessa forma você não corre o risco de enviar uma versão da UI.Financeiro.dll com outra versão (possivelmente incompatível) da Entidade.Financeiro.dll, por exemplo

Fica como sugestão, para você pensar nos benefícios das duas abordagens e decidir o que é melhor pra você.

Forte abraço,

André Borges Medeiros
MCPD, MCT

>> Se a resposta solucionar sua dúvida, favor Votar como Útil

Answer 4

Muito Obrigado André,

abriu a mente para algumas coisas.
Como você não citou, vou levar em consideração que em questões de performance é irrelevante, estaria certo ao pensar nisso?

Abraços e mais uma vez muito obrigado

---

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" (Martin Fowler)

Answer 5

Oi Leandro.

É verdade, a principio não teríamos maiores implicações com relação a performance.

Forte abraço,

André Borges Medeiros
MCPD, MCT

>> Se a resposta solucionar sua dúvida, favor Votar como Útil