Dúvida em usar DTO ao invés da própria entidade

[db]

Olá, boa tarde.

Primeiramente, me desculpem se as dúvidas são básicas.

Pessoal, quando uso DTO (Data Transfer Object) e quando uso a própria entidade numa aplicação JSF?

A camada Web pode acessar diretamente os objetos do domínio?

Os backing beans utilizam DTOs para se comunicarem com EJBs ou Service's?

Desde já agradeço.
att
--db

[Danilo Magrini]

2009/10/30 db <dbco...@gmail.com>:

Se você usa EJB3 não tem mais porque usar DTO. DTO foi um workaround
para uma tecnologia problemática como EJB2.x

[Rafael Meireles]

Vc vai precisar eventualmente utilizar o padrao TO Assembler, pra quando suas listagens
precisar de mais campos do que a sua entidade possui.

2009/10/30 Danilo Magrini <danilo....@gmail.com>

--
Atenciosamente,
--------------------------------------------
Rafael Meireles Caetano
Arquiteto Java EE
Equipe de Arquitetura CGDT
Fone: +55 85 8811-1806

[Bruno Maomeh]

quando eu preciso de mais campos que a mina entidade possui, eu adiciono os campos a ela declarando esses campos novos como @Transient

2009/10/30 Rafael Meireles <rafaelm...@gmail.com>

--
Bruno Maomeh
  http://brunomaomeh.wordpress.com

[Rafael Meireles]

ai vc esta criando dependencia da entidade com necessidades da tela, são para estes casos q existe o pattern.

2009/10/30 Bruno Maomeh <bruno...@gmail.com>

[db]

Obrigado Danilo e Rafael.

Isto quer dizer que, ao invés da minha página JSF acessar objetos da minha classe de domínio Funcionário, ela deve acessar por exemplo objetos FuncionarioDTO, que são obtidos através dos EJBs?

Ou eu posso acessar EJBs diretamente da página JSF, ou acessar EJBs a partir dos managed beans? Isto pode aumentar o acoplamento entre o modelo e a visão. Isto é ruim?

abs e obrigado
--db

2009/10/30 Rafael Meireles <rafaelm...@gmail.com>

[Rafael Meireles]

hj vc pode acessar os EJB a partir do bean do jsf pois a injeção sera feita e a dependencia sera com a interface
nao importando se eh EJB ou nao.

2009/10/30 db <dbco...@gmail.com>

[Marcelo Balloni]

 Uma vez que a visão é a representação da model e a controler é intimamente ligada a visão essas podem ser dependentes do model, o inverso nunca.

2009/10/30 db <dbco...@gmail.com>

[db]

Aah entendi...

Mas isso também é verdade se a aplicação for em camadas? Quero dizer, se as camadas vão  se comunicar pela rede, tenho que usar DTO, né?

2009/10/30 Marcelo Balloni <marcelo...@gmail.com>

[Marcelo Balloni]

 De alguma maneira eles devem trocar informações, correto?
 O nome DTO anda meio em desuso, na verdade é muito difícil dizer qual é correto e qual é incorreto, mas pra ser mais sincero ainda é uma discução que geralmente gera brigas hehehe.
 Aqui tem uma discução legal: http://www.guj.com.br/posts/list/31773.java

2009/10/30 db <dbco...@gmail.com>

[db]

Essa discussão é sobre vários achismos, mas não existe nenhuma referência. Digo, se vc afirma que "TO, VO, DTO e POJO são iguais", tem que dar as referências que o levou a acreditar nisso.

Um dos objetivos dos padrões era a utilização de uma linguagem comum em que se a pessoa A fala a B que utilizou DTO para resolver o problema de comunicação entre camadas, B entende. (Design Patterns, p. 13).

É interessante rotular as coisas porque fica mais fácil de entender, embora dois objetos identicamente rotulados possam ser extremamente diferentes, contidos no limite do rótulo. De acordo com Paulo Brabo, "[...] o protagonista de O Perfume, de Patrick Süskind, não compreendia o onipresente contra-senso que era chamar todos os dias de “leite” uma substância cuja cor, composição, aroma e aspecto geral variava tão notavelmente a cada manhã. A realidade era para ele de uma riqueza que o rótulo estava longe de poder abarcar" (http://www.baciadasalmas.com/2006/sobre-dar-nomes-a-primatas/).

O problema é que para cada indivíduo, DTO é uma coisa diferente.

DTO, segundo Fowler, é usado para encapsular dados requisitados por um cliente remoto. Quer dizer, ao invés de fazer n chamadas para obter n dados, faz-se 1 chamada para obter 1 objeto com estes dados. Ainda, Fowler diz que o pessoal da Sun chama isso de VO.

Baseado nas respostas de todos vocês (agradeço muito), posso concluir que:
- Posso utilizar DTO para se comunicar entre as camadas. Isto é bom quando há separação física e meus objetos de domínio tem coleções lazy; e
- Se não há separação física, posso utilizar as classes do domínio na camada de visão.

Estou certo?
Muito obrigado
abs
--db

2009/10/31 Marcelo Balloni <marcelo...@gmail.com>

[Rafael Ponte]

Dica, compre e leia o livro do Fowler, Patterns of Enterprise Application Architecture. Ele é a melhor referência que você pode ter sobre o assunto. Qualquer arquiteto de software, alias qualquer desenvolvedor também, que se preze já leu este livro no mínimo um vez na vida.

Resumindo a estória toda:

DTO só faz sentido se você estiver trabalhando com camadas fisicas (tiers e não layers), pois trafegar dados na rede via chamadas remotas é muito caro, caso contrário trabalhe diretamente com os objetos de domínio. Não há qualquer problema nisso. Existem também os Local DTOs, na qual são DTOs que não transitam entre camadas fisicas e  existem para satisfazer necessidades especificas, como por exemplo a camada de apresentação.

Abraços.

2009/10/31 db <dbco...@gmail.com>

--
Rafael Ponte
http://www.rponte.com.br

[Rafael Ponte]

O que o Meireles falou é correto, Bruno. Você não deveria construir seu modelo baseado nas necessidades da camada de apresentação. A idéia de usar @Transient está mais ligada em complementar o modelo com atributos/estados não persistíveis. Claro que há momentos que é mais simples inserir um atributo a mais no modelo para facilitar na camada de apresentação, mas é bom ser muito criterioso sobre isso.

2009/10/30 Rafael Meireles <rafaelm...@gmail.com>

[Rafael Ponte]

Esse tal de TO Assembler, também padrão da Sun, é a mesma coisa do DTO do Martin Fowler. Para falar a verdade ele é um nome bonitinho que a Sun criou para um TO "gordo", e só. No final é a mesma coisa, sem tirar nem pôr.

Na verdade o db vai precisar mesmo é de um Local DTO para casos especificos, mas para 99% dos casos ele irá trabalhar com as entidades do modelo mesmo. Isso claro, levando em consideração que estejamos falando de layers (camadas lógicas).

2009/10/30 Rafael Meireles <rafaelm...@gmail.com>

[L3Lo]

Alto nível a discussão. Muito legal!!!
Concordo com o Rafael Ponte. DTO multiplica a quantidade de classes
necessárias na aplicação, dificulta o desenvolvimento e a manutenção.
Só valerá a pena se houver divisão absoluta entre as camadas. Com EJB
3 não vale a pena.
Eu só costumo usar quando tenho que construir um Serviço que será
consumido por equipe com a qual tenho o mínimo contato, aí é
necessário uma assinatura de serviços e objetos estável e bem
definida.
Quanto ao usar o @Transient nos Entities, sem uma necessidade do
domínio, somente para satisfazer a um elemento visual, isso aumenta o
acoplamento e diminui a coesão das classes, é mais rápido para
construir e mais difícil de manter. Eu costumo usar o padrão Wrapper
ou até mesmo usar implementar o Bridge no ManagedBean. Aí depende do
caso real, mas sempre resolvendo na camada de visão,.

DB, acredito que as suas conclusões são corretas.


Abraços.

On 1 nov, 12:00, Rafael Ponte <rpo...@gmail.com> wrote:
> Esse tal de TO Assembler, também padrão da Sun, é a mesma coisa do DTO do
> Martin Fowler. Para falar a verdade ele é um nome bonitinho que a Sun criou
> para um TO "gordo", e só. No final é a mesma coisa, sem tirar nem pôr.
>
> Na verdade o db vai precisar mesmo é de um Local

> DTO<http://martinfowler.com/bliki/LocalDTO.html>para casos

> especificos, mas para 99% dos casos ele irá trabalhar com as
> entidades do modelo mesmo. Isso claro, levando em consideração que estejamos
> falando de layers (camadas lógicas).
>

> 2009/10/30 Rafael Meireles <rafaelmeire...@gmail.com>

>
>
>
>
>
> > Vc vai precisar eventualmente utilizar o padrao TO Assembler, pra quando
> > suas listagens
> > precisar de mais campos do que a sua entidade possui.
>

> > 2009/10/30 Danilo Magrini <danilo.magr...@gmail.com>
>
> >> 2009/10/30 db <dbconr...@gmail.com>:

> >> > Olá, boa tarde.
>
> >> > Primeiramente, me desculpem se as dúvidas são básicas.
>
> >> > Pessoal, quando uso DTO (Data Transfer Object) e quando uso a própria
> >> > entidade numa aplicação JSF?
>
> >> > A camada Web pode acessar diretamente os objetos do domínio?
>
> >> > Os backing beans utilizam DTOs para se comunicarem com EJBs ou
> >> Service's?
>
> >> Se você usa EJB3 não tem mais porque usar DTO. DTO foi um workaround
> >> para uma tecnologia problemática como EJB2.x
>
> > --
> > Atenciosamente,
> > --------------------------------------------
> > Rafael Meireles Caetano
> > Arquiteto Java EE
> > Equipe de Arquitetura CGDT
> > Fone: +55 85 8811-1806
>
> --

> Rafael Pontehttp://www.rponte.com.br- Ocultar texto das mensagens anteriores -
>
> - Mostrar texto das mensagens anteriores -

[Walter Mourão]

Olá amigos,

Alto nível a discussão. Muito legal!!!
Concordo com o Rafael Ponte. DTO multiplica a quantidade de classes
necessárias na aplicação, dificulta o desenvolvimento e a manutenção.
Só valerá a pena se houver divisão absoluta entre as camadas. Com EJB
3 não vale a pena.

Concordo que deve ser um muito chato ficar escrevendo DTOs na mão. Eu os uso sempre, pois gosto de manter os serviços bem desconectados da implementação da persistência e com assinatura bem definida.
Não entendi porque "com EJB 3 não vale a pena"... o que ele traz de diferente nesse sentido ?

Sds,

Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br

2009/11/1 L3Lo <wsam...@gmail.com>

[Assis Júnior]

Cara essa questão do @Transite é uma questão polêmica.
Já trabalhei em um sistema onde usavam muitos transientes e a
manutenção é extremamente complicada. Quando vc sai da funcionalidade
que gerou a necessidade do transiente não sabe mais nem porque ele
existe.

Não recomendo o transiente para satisfazer somente a view. Dá para
criar melhores soluções nessa camada ou mesmo no managed bean.

2009/11/2 Walter Mourão <walter...@gmail.com>:

--
Atenciosamente,
Assis júnior
SCJP 5.0 Certified

[Wandrey]

O problema era com EJB 2, na época do j2ee e tal, era um tal do BOLOVO
pra lá BOLOVO pra cá e quase nunca os objetos trafegavam entre as
camadas(tiers), agora com soa e webservice ta fácil.
Baseado em minha experiência, sempre utilizo entidades do domínio,
quando por alguma necessidade específica(relatórios, transporte e
simplificações), a classe de serviço específica, cria os VO
necessários, exemplo:
ProdutoService, manipula produto e seus relacionamentos/
responsabilidades, mas para alguns relatórios, não são necessários
todas as informações como por exemplo, preço, histórico de preço,
venda, estoque e etc, então é criado um
List<ProdutoVO>converteProtutoVO(List<Produto>), dessa forma um
Produto Light, o nosso querido VO(Value Object) é utilizado, ele não é
um objeto do domínio, mas uma simplificação uma abstração ou até pode
encapsular/agregar outros objetos;
Nesta abordagem os objetos de domínio(entitys da vida) já estão em
memória e uma rápida transformação é realizada.
Para casos onde mais desempenho é necessário, o próprio serviço,
quando recuperar os dados do banco, já trará apenas os necessários,
exemplo
createQuery("SELECT new ProdutoVO e por ai vai.

Agora, cuidado com o transient, se estão adicionando campos na
entidade que não tem a ver com o domínio e sim com controle e visão é
um problema, exemplo clássico, boolean selecionado, marcado e etc,
informações da camada view e controller, que poderiam ser contornado
com um <Boolean,Produto>.
Outro problema é a falta de coesão, se estão usando objetos leves, as
decisões, tranformações e regras de negócio devem estar na classe de
serviço, exemplo o ProdutoService. Produto não teria um transiente,
getHistórico de Vendas, o local correto, segundo as melhores práticas
seria em ProdutoService, onde as regras de negócio e colaboração com
objetos ricos são realizadas.

On 2 nov, 12:25, Assis Júnior <assisp...@gmail.com> wrote:
> Cara essa questão do @Transite é uma questão polêmica.
> Já trabalhei em um sistema onde usavam muitos transientes e a
> manutenção é extremamente complicada. Quando vc sai da funcionalidade
> que gerou a necessidade do transiente não sabe mais nem porque ele
> existe.
>
> Não recomendo o transiente para satisfazer somente a view. Dá para
> criar melhores soluções nessa camada ou mesmo no managed bean.
>

> 2009/11/2 Walter Mourão <walter.mou...@gmail.com>:

>
>
>
>
>
> > Olá amigos,
>
> >> Alto nível a discussão. Muito legal!!!
> >> Concordo com o Rafael Ponte. DTO multiplica a quantidade de classes
> >> necessárias na aplicação, dificulta o desenvolvimento e a manutenção.
> >> Só valerá a pena se houver divisão absoluta entre as camadas. Com EJB
> >> 3 não vale a pena.
>
> > Concordo que deve ser um muito chato ficar escrevendo DTOs na mão. Eu os uso
> > sempre, pois gosto de manter os serviços bem desconectados da implementação
> > da persistência e com assinatura bem definida.
> > Não entendi porque "com EJB 3 não vale a pena"... o que ele traz de
> > diferente nesse sentido ?
>
> > Sds,
>
> > Walter Mourão
> >http://waltermourao.com.br
> >http://arcadian.com.br
> >http://oriens.com.br
>

> > 2009/11/1 L3Lo <wsama...@gmail.com>

> >> > Rafael Pontehttp://www.rponte.com.br-Ocultar texto das mensagens

> >> > anteriores -
>
> >> > - Mostrar texto das mensagens anteriores -
>
> --
> Atenciosamente,
> Assis júnior

> SCJP 5.0 Certified- Ocultar texto das mensagens anteriores -

[Wellington Souza Amaral]

A razão é basicamente essa que o Wandrey disse. Só acrescento que se perde muito tempo construindo e mantendo um DTO. Só faço isso se for necessário e os benefícios compensarem o esforço extra.
Abraços.


________________________________

> >http://waltermourao.com.br <http://waltermourao.com.br/>
> >http://arcadian.com.br <http://arcadian.com.br/>
> >http://oriens.com.br <http://oriens.com.br/>

[Marcelo Balloni]

  Abri uma única exceção para criação de atributos transientes.
 Concordo que isso dificulta a manutenção e aquele monte de coisas como coesão e acoplamento, fica realmente muito acoplado devido a particularidades da view, lembrando que o dominio (model) tem influencia total sobre a view, o inverso nunca.
 quanto ao comentário sobre WebServices, a experiência que tive com isso nao foi nem um pouco agradavel. A engenharia exigiu o uso de webservices como uma especie de façade do model (disse especie pq se comportava semelhantemente a um mas nao era um por mais uma serie de outros fatores). Resumindo, isso deixou o sistema muito de vagar, o cliente quase cancelou o projeto e remover esses webservices fez A diferença.
 Numa palestra sobre SOA o palestrante comentou sobre empresas que dizem implementar SOA e enchutam o sistema de webservices.
 Bom, isso é outro assunto.

 Quanto a DTOs acredito que se puder usar os objetos de entidades na camada da view beleza, nao vejo mal algum nisso.

2009/11/2 Wellington Souza Amaral <welling...@tjrj.jus.br>

[Rafael Ponte]

Na maioria das vezes não compensa. São cenários especificos que te levam a usar DTOs.

2009/11/2 Wellington Souza Amaral <welling...@tjrj.jus.br>

[Assis Júnior]

Cara, também já tive problemas com webservices. Eu possuía um ws que
usava uma entidade do sistema com vários relacionamentos e a
transferência de dados ficava lenta. (JAVA/DOT NET) Solução para isso
foi criar um DTO somente com os dados necessários.

2009/11/2 Marcelo Balloni <marcelo...@gmail.com>:

[Pedro Neves]

Eu também estou fazendo isso que o Assis Júnior falou.

Usamos os DataTypes ou DTOs gerados a partir do WSDL ou XSD.

Att,
Pedro Neves

2009/11/3 Assis Júnior <assi...@gmail.com>:

[Rafael Ponte]

Mas é para isso que o padrão existe :-)

Quando a funcionalidade é bem simples, e a quantidade de dados necessárias também, não há problemas em usar a entidade do domain model. Mas se a entidade passou do trivial, possuindo relacionamentos e lógica de negócios eu descartaria a idéia de utiliza-la para transportar dados, por estes e outros motivos. É aí entra em ação nosso famigerado DTO.

2009/11/3 Assis Júnior <assi...@gmail.com>

[Danilo Magrini]

2009/11/8 Rafael Ponte <rpo...@gmail.com>:

db,

eu gostaria muito de poder participar dessa discussão mas infelizmente
estou sem um pingo de tempo para sequer escrever. Segue um artigo
pequeno (o ideal é ir mais a fundo nesse conceito obtendo o livro e
etc) que retrada um pouco sobre o que penso em realação a discussão.
Qualquer dúvida, assim que eu me desafogar um pouco poderiamos
conversar sobre isso novamente quem sabe até tomando um cafézão por
aqui né? hehehe Segue:
http://www.martinfowler.com/bliki/AnemicDomainModel.html

abraço.

--
Danilo G. Magrini
danilo.magrini (AT) gmail (DOT) com
GPG Key: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x3EAD0BBAFDE75A11
"Any fool can write code that a computer can understand. Good
programmers write code that humans can understand." (Martin Fowler)