Pergunta na lista UML-BR:
Boa tarde a todos,
Estava estudando o DDD (Domain Drive Design)…
Percebi que a camada de negócios deve ser um reflexo da realidade, para que
o sistema possa evoluir de maneira mais fácil (flexibilidade) conforme a
regra de negócios do cliente tb muda…
Por isso temos as entidades.. Por exemplo Funcionario, Departamento, etc…A duvida que eu tenho é a seguinte:
Vamos supor que eu tenha que exibir todos os funcionários em um JSP… eu
deveria criar um DTO do Funcionario e “mandar” para a camada de visão? ou
posso mandar o proprio objeto de negócio (o que na minha opinião é mais
pratico, já que eu não preciso duplicar código no DTO)?
Pois eu li o Artigo do Phillip Calçado e do Martin Fowler
http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
http://www.martinfowler.com/bliki/AnemicDomainModel.html
onde eles dizem que não é bom criar DTO´s… e por isso estou confuso….O que vcs acham… para exibir as entidades em tela a camada de visão pode
ter contato com as entidades… ou vou ter que duplicar o código criando um
DTO para cada entidade?[...]
Então eu tb penso assim….
Mas pensando no lado negativo disso, imagine se eu tiver 50 JSP´s mostrando
os dados desse Funcionario…. Ai eu vou e faço uma refatoração no codigo
(talvez mudando metodos de uma classe pra outra, etc)…. vou ter que
verificar nos 50 JSP´s pra ver se não deu nenhum problema, ou até mesmo para
ajusta-los a nova mudança!!!!!
Talvez se eu criasse DTO´s para isso eu não teria esse problema pois os
DTO´s não mudariam…..
O que vcs acham disso…. faz sentido????valeu pessoal…..
Felipe Regalgo
Você poderia ter objetos de transferência apenas para a interface - DDD
não fala explicitamente sobre isso- mas existem algumas questões
práticas neste sentido:- Hierarquia duplicada desnecessariamente: Ao manter um DTO (VO é um
nome que já foi usado para DTOs mas não é mais) para isso você está
duplicando toda a sua hierarquia de classes, o que indica código
duplicado, tendo em dois ou mais lugares no seu sistema o mesmo
conceito implementado.- Mudanças: Da mesma maneira que se eu alterar minha classe de
negócios vou ter que alterar a interface sem DTOs, com DTOs a cada
mudança no meu modelo de negócios *eu tenho que alterar o DTO
correspondente em si*, logo você só transfere o problema de lugar mas
continua com ele -e com código duplicado que é *muito* ruim.- Se você pensar neste isolamento então precisa de DTOs para qualquer
coisa que não seja camada de negócios, logo vai precisar também para
persistência, por exemplo, caindo nos mesmos problemas acima para
outra camada.- Encapsulamento: OO exige que suas abstrações sejam encapsuladas, e
isso quer dizer que dificilmente a mudança na implementação de uma
classe vai afetar outras em tão grande escala. Quando isso acontece é
porque houve um grande refactoring ou uma grande mudança de conceito de
negócios, e isso -além de raro- vai afetar seu sistema com ou sem
DTOs. A diferença, como citando no primeiro item, é que sem DTOs você
não precisa se preocupar em mudar vários lugares, apenas a classe de
negócios.- Conceito de Negócios: DDD pressupõe que seu sistema modela ao mais
próximo da realidade possível. Se uma classe muda no modelo de
negócios é porque seu entendimento sobre o negócio mudou e
provavelmente alguma coisa na interface vai refletir isso.Em DDD temos os ContextMappers que mapeiam domínios diferentes que
precisam se comunicar. Esta é a abordagem normal para os casos onde se
percebe a necessidade de algo como um ‘DTO interno’.‘DTOs internos’ (”VOs”) são uma péssima prática, completamente não OO
e difundidas tristemente pela Sun para lidar com as falhas da
arquitetura de EJBs pré 3.0.[]s