DTO - dúvida conceitual

JavaEvangelist Membro desde: 09/10/2003 14:23:31 Mensagens: 379 Offline

Esse assunto é muito jóia...

Eu enfatizo que o conceito do padrão é mais importante que a estrutura. Veja:

O que vc está dizendo é que se eu pegar um pojo da vida o fizer serializable

ok

e colocar um monte de codigo de validação,

A validação pode ficar nos setters, correto!? Se os getter e setters só atribuirem/devolverem os valores da propriedades seriam só idiossincrasia para acessar a propriedade internas do objeto.

colocar o construtor privado,

Huh(vamos ver...)

colocar get/set paras os atributos,

ok

colocar um método estático para retornar o objeto que eu crio dando clone de um atributo estático privado e final na classe

Ops...

eu estarei usando : Prototype (clone copy),

ok! Se é interessante clonar seu objeto, não tem nada de errado com isso. Ainda não vi a motivação mas pode ser que faça sentido. Sei lá, vai ver que você esteja fazendo um joguindo de carros e o servidor disponibiliza novos modelos de carros. Cada cliente recebe os modelos de carro e permite que usuário faça modelos personalizados a partir desses. (Serializável e clonável). Nesse caso o modelo segue o Prototype.

Factory-Method (método de criação),

Aí não. Eu falei que o conceito do padrão é importante, não a estrutura. Usar um método para criar outro não faz um "factory method". Existe uma motivação para o Factory Method e não existe nenhuma motivação na saladinha.

TO (serializable)

Pode ser que sim... desde que a motivação coincida com o padrão. No exemplo do jogo do carrinho seria uma estupidez os clientes serem informados de propriedade por propriedade de cada modelo. É mais inteligente o servidor enviar todo o objeto. Esse é um exemplo do uso do DTO.

e Bean (get/set).

Isso também não. Para começar que um Javabeans é um componente de software, não um padrão. E existe uma especificação que dita quando uma classe Java pode ser chamada de Javabeans... De forma simplificada:

The class must have a no-argument public constructor. This allows easy instantiation within editing and activation frameworks.
The class properties must be accessible using get, set, and other methods (so-called accessor methods), following a standard naming convention. This allows easy automated inspection and updating of bean state within frameworks, many of which include custom editors for various types of properties.
The class should be serializable. This allows applications and frameworks to reliably save, store, and restore the bean's state in fashion that is independent of the VM and platform.

Ainda no exemplo dos carrinhos, o código não precisa ser um padrão. Mas, alguns padrões podem ser encontrados na resolução desse problema.

ArrayLisr , etc... sim são estratégias de List que por sua vez é estratégia de Collection. Isso sim. Mas nunca "interface" per se será um padrão.

Concordo plenamente!!!

Sobre a parte de corolários, etc... acho que não podemos fazer tal afirmação. A demonstração rigorosa que um padrão deriva matematicamente de "axiomas de OO" não deve ser alguma coisa fácil, talvez nem seja possível... Seria realmente incrível provar que dado um contexto(limitações) e um problema (necessidades) não seria possível encontrar um modelo melhor do que o modelo de um certo padrão. Mas por enquanto isso é uma especulação (conjectura) não um teorema.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

rodrigousp wrote:

TO (serializable)

Pode ser que sim... desde que a motivação coincida com o padrão. No exemplo do jogo do carrinho seria uma estupidez os clientes serem informados de propriedade por propriedade de cada modelo. É mais inteligente o servidor enviar todo o objeto. Esse é um exemplo do uso do DTO.

e Bean (get/set).

Isso também não. Para começar que um Javabeans é um componente de software, não um padrão. E existe uma especificação que dita quando uma classe Java pode ser chamada de Javabeans... De forma simplificada:

Vc passou longe do ponto. O ponto era :misturar um monte de pedaços de cada padrão não significa usar o padrão.
Tlv vc defenda que o conceito do padrão é mais importante que a implementação. Tudo bem. Mas não era isso que o blog que vc apontou como justificativa defendia. Ha uma enorme confusão de padrões lá. Era disso que estava falando.

Eu não falei em javabean eu falei em bean. Sim, JavaBean é um componente e uma especifiação, mas bean é algo mais simples.
Todos os javabeans são beans, mas o contrário não é verdade.

Sobre a parte de corolários, etc... acho que não podemos fazer tal afirmação. A demonstração rigorosa que um padrão deriva matematicamente de "axiomas de OO" não deve ser alguma coisa fácil, talvez nem seja possível... Seria realmente incrível provar que dado um contexto(limitações) e um problema (necessidades) não seria possível encontrar um modelo melhor do que o modelo de um certo padrão. Mas por enquanto isso é uma especulação (conjectura) não um teorema.

Dificil ? ... hummm... não importa se é difícil, importa que é possível. O ponto é que padrão tlv sejam encontrados empiricamente, mas eles têm uma base teórica. Sem ela, não existe padrão. É no máxima uma boa prática e no pior caso uma gambiarra.
Mas nem é tão dificil assim:
O padrão Composite, por exemplo, nasce diretamente do conceito de composição que é uma forma de relacionar objetos.
O padrão Composite não é qualquer tipo de composição. É um tipo especial onde o composto é da mesma classe do componente. è isso que marca a diferença e o padrão. Não é difícil entender que composição é uma relação de objetos diretamente derivada do próprio conceito de objeto e portanto o Composite é um padrão derivado matematicamente de axiomas OO ( a existência de objetos é o primeiro axioma)

This message was edited 2 times. Last update was at 11/08/2008 09:12:55

Vc passou longe do ponto.

Desculpa ai (1)... Eu estava só provando o que eu havia falado antes: que o padrão DTO NÃO dita um Objeto anêmico.

Eu não falei em javabean eu falei em bean.

Desculpa ai (2) ... Na literatura que eu conhecia, beans e Javabeans eram sinônimos. E um Javabeansprecisava ter construtor sem parâmetros público. Então apesar dos getters e setters, não poderíamos chamar aquele exemplo de Javabeans.

Mas nem é tão dificil assim:
O padrão Composite, por exemplo, nasce diretamente do conceito de composição que é uma forma de relacionar objetos. (...)

Eu não diria que esta essa é a demonstração mais formal que conheço. Na minha opinião seria preciso tomar o padrão composite, como apresentado pelo Gof e sua "Estrutura": Component, Composite and Leaf. Então, seria preciso demonstrar que aplicando os aximos do OO teríamos essas entidades e teríamos que tomar o cuidado para mostrar como cada uma dessas partes atuam não deixando dúvidas se Component pode ou não ter
métodos de manipulação de listas, se um autorelacionamento pode ou não desempenhar o papel de composição, etc.

Eu concordo plenamente que existe uma base teórica importante sobre os padrões de projeto.
Mas volto a enfatizar que o conceito é mais importante que a estrutura.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

rodrigousp wrote:

Mas nem é tão dificil assim:
O padrão Composite, por exemplo, nasce diretamente do conceito de composição que é uma forma de relacionar objetos. (...)

Eu não diria que esta essa é a demonstração mais formal que conheço.

Não foi intenção ser formal. Embora "formal" seja relativo aqui.

Na minha opinião seria preciso tomar o padrão composite, como apresentado pelo Gof e sua "Estrutura": Component, Composite and Leaf.

Ora ai é que está. Porque como paresentado pelo GoF ? Eles são algum tipo de deuses ? E aliás as ideias deles são para C++
Se é verdade que a base toerica é mais importante que a implementação não importa que seja em C++, mas vai dai, também não importa que seja do GoF.

Então, seria preciso demonstrar que aplicando os aximos do OO teríamos essas entidades e teríamos que tomar o cuidado para mostrar como cada uma dessas partes atuam não deixando dúvidas se Component pode ou não ter
métodos de manipulação de listas, se um autorelacionamento pode ou não desempenhar o papel de composição, etc.

não. A implementação é irrelevante. métodos de manipulação de listas são irrelevantes. Podem ser adicionados se necessário Por exemplo, se a composição for imutável esses métodos não podem existir. Mas isso é detalhe de implementação.
Auto-relacionamento é um tpo de relacionamento e portanto auto-relacionamento pode ser composição e pode ser visto como um corolário do padrão. Esse tipo de coisas não entram no padrão.

O padrão é definido como a composição (operação entre objetos) recursiva. Ou seja, um objeto da classe X pode ser composto por objetos da classe X. É só isso. (Em uml um tipo - classe, interface - tem relação de composição consigo mesmo. )

Se o objeto composto é adicionado a si mesmo é uma auto-composição ( um ciclo fechado) Se o objeto não é composto por mais nenhum objeto então ele é diretamente um leaf. Ou seja, o leaf advém da propria regra e não é necessário presupor a sua existencia à partida.

Se o objeto leaf é especializado isso não é mais um problema do padrão Composite. Isso é a implementação de outro padrão: Strategy. Normalmente isso é legal ( Swign por exemplo) mas não é uma condição sin qua non para ter composite.

Ou seja, o ponto, é que não é tão complexo assim derivar as coisas, mas a principio isso não é feito no dia-a-dia, dai a necessidade de catálogos. Tlv os catálogos não enfatizem o suficiente a relação que os padrões têm com as regras de OO. Isso é uma pena, porque leva muita gente a achar que padrões são coisas apenas empíricas.

É que achando que são apenas empíricas sentem-se no direito das dobrar à sua situação, descaracterizando os principios de OO e portanto o padrão.

O exemplo classico: o cara cria um objeto com variável static private e um método para retorna essa instancia. Ai ele diz que isso é a implementação de singleton. Esse é o problema. Não é a implementação de singleton pela simples razão que não cumpre as regras do padrão em particular : um único objeto da classe deve existir a qualquer momento.
( se o construtor é publico, por exemplo, outros objetos podem ser criados.)

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2030 Offline

Ressucitando um tópico do passado ...

Lendo algumas referências, inclusive muitas apresentadas aqui, consigo entender o que é o DTO e quando usar.

Agora a minha dúvida é bem pontual.

Suponha que eu tenha um método de acesso ao banco que me retorna um result set, eu preciso que este método retorne para o cliente - a camada que vai usá-lo, seja view ou business sei lá - uma lista formatada que seja de fácil iteração.

O que eu quero dizer com isso? Quando eu faço

Fica fácil no meu cliente saber iterar na lista e fazer o que for preciso.

Mas isso seria ruim? Pois a classe Pessoa muito provavelmente só teria sentido em ter os seus atributos e os seus gets e sets.

Uma sugestão - primeira página do tópico - seria passar o que o programmer chamou de um array de structs tipados.

Eu já tinha visto esta alternativa antes, mas isso pode ser ruim pois eu toda classe que precisasse eu teria que ter uma estrutura dessas.

Uma outra alternativa seria você criar um hashmap e depois um iterator pra facilitar as coisas. Mas será que o esforço vale a pena?

Achei um link interessante que trata da mesma situação

http://consultingblogs.emc.com/jaddy/archive/2009/10/01/how-not-to-use-dtos-in-domain-driven-architectures.aspx

Na sessão Our solution ele diz

From coding perspective, we used beanutils and a bit of reflection to achieve cloning of objects.

Seria essa uma boa idéia? Não seria um tiro de canhão para matar uma mosca??

O que vocês costumam fazer? Ou usam o VO Pessoa mesmo??

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2030 Offline

cv wrote:O grande ponto a se grifar eh o "se voce tem uma aplicacao distribuida...": DTOs sao um design pattern, Local-DTOs sao um anti-pattern.

a minha duvida tem a ver com a frase acima tb, no caso que eu coloquei não tenho uma aplicação distribuida ...

André Fonseca wrote:a minha duvida tem a ver com a frase acima tb, no caso que eu coloquei não tenho uma aplicação distribuida ...

Como que é sua aplicação?

É client x server?

flws

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2030 Offline

sim, entretanto as camadas que eu mencionei rodam no mesmo ambiente. eu posso até estar fazendo acesso a um banco de dados remoto, mas não há necessiade de trafegar estes objetos pela rede...

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

André Fonseca wrote:Ressucitando um tópico do passado ...

Lendo algumas referências, inclusive muitas apresentadas aqui, consigo entender o que é o DTO e quando usar.

Agora a minha dúvida é bem pontual.

Suponha que eu tenha um método de acesso ao banco que me retorna um result set, eu preciso que este método retorne para o cliente - a camada que vai usá-lo, seja view ou business sei lá - uma lista formatada que seja de fácil iteração.

O que eu quero dizer com isso? Quando eu faço

List list = new ArrayList(); while (rs.next()) { Pessoa p = new Pessoa(); p.setNome(rs.getString("nome")); p.setIdade(rs.getInt("idade")); list.add(p); }

Fica fácil no meu cliente saber iterar na lista e fazer o que for preciso.

Mas isso seria ruim? Pois a classe Pessoa muito provavelmente só teria sentido em ter os seus atributos e os seus gets e sets.

Uma sugestão - primeira página do tópico - seria passar o que o programmer chamou de um array de structs tipados.

Eu já tinha visto esta alternativa antes, mas isso pode ser ruim pois eu toda classe que precisasse eu teria que ter uma estrutura dessas.

Uma outra alternativa seria você criar um hashmap e depois um iterator pra facilitar as coisas. Mas será que o esforço vale a pena?

Achei um link interessante que trata da mesma situação

http://consultingblogs.emc.com/jaddy/archive/2009/10/01/how-not-to-use-dtos-in-domain-driven-architectures.aspx

Na sessão Our solution ele diz

From coding perspective, we used beanutils and a bit of reflection to achieve cloning of objects.

Seria essa uma boa idéia? Não seria um tiro de canhão para matar uma mosca??

O que vocês costumam fazer? Ou usam o VO Pessoa mesmo??

Se a sua aplicação é orientada ao dominio obrigatoriamente vc terá uma List<Entidade> e portanto vc é obrigado a criar objetos dessa entidade.
Contudo, vc não é obrigado a criar esses objetos à mão, nem a criá-los junto à leitura do resultSet.

Para não os criar à mão vc usa reflection. Todos os frameworks fazem isso. Conceptualmente isso não passa de uma forma de injeção. Vc injeta um monte de outros objetos na classe da entidade.
O fato deles serem dados da entidade é um detalhe.

Vc não precisa criar o list e populá-lo com a leitura do resultset; Vc pode usar o padrão Fastlane Reader. Este padrão poupa objetos na memoria e apenas traduz o rs para o objeto quando necessário.
Nestes casos o uso de List ou outro tipo de collection não é aconcelhável a menos que vc tenha codigo legado escrito dessa forma.

Você pode abstrair esse codigo até ter algo que funciona para qualquer classe. Basicamente vc estará fazendo o que o Hibernate faz. Mas para isso dar certo vc precisa de algum tipo de metadados.
Sem metadados o unico jeito e´fazer na mão. Reflection oferece muitos metadados, mas podem ñ ser suficientes. Por exemplo, não contém nome de tabelas e colunas...

Este tipo de trabalho não se caracteriza como o uso de DTO. O uso de DTO implica duas coisas : orientação a dados (data) e distribuição (transfer). Usar entidades descaractetiza o uso de dados e o fato de estarem na mesma jvm descaracteriza transfer ( todos os DTO são serializable, entidades não precisam ser).

Cuidado com a confusão entre DTO e VO. Tem muita coisa sobre isso no guj é questão de procurar, mas resumindo : VO não são DTO e DTO não são VO.

sergiotaborda wrote:Este tipo de trabalho não se caracteriza como o uso de DTO. O uso de DTO implica duas coisas : orientação a dados (data) e distribuição (transfer). Usar entidades descaractetiza o uso de dados e o fato de estarem na mesma jvm descaracteriza transfer ( todos os DTO são serializable, entidades não precisam ser).

Cuidado com a confusão entre DTO e VO. Tem muita coisa sobre isso no guj é questão de procurar, mas resumindo : VO não são DTO e DTO não são VO.

Sendo assim (client x server), também concordo com que o Sergio disse.

flws

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

Achei interessante (porque reflete a situação do Java) é que a opção mais simples que é do hashmap é considerado um "esforço".

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

mochuara wrote:Achei interessante (porque reflete a situação do Java) é que a opção mais simples que é do hashmap é considerado um "esforço".

Existe uma derivação do DTO chamada HashDTO que usa um map para a transferencia. O problema é que isso não é fortemente tipado e leva a um monte de outros problemas.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

sergiotaborda wrote:

mochuara wrote:Achei interessante (porque reflete a situação do Java) é que a opção mais simples que é do hashmap é considerado um "esforço".

Existe uma derivação do DTO chamada HashDTO que usa um map para a transferencia. O problema é que isso não é fortemente tipado e leva a um monte de outros problemas.

Ele é fortemente tipado, é um hashmap.

Não é um tipo específico da sua aplicação, e nem vejo motivo para tal, visto que é apenas para trafegar objetos entre modulos distintos. Não ter que manter código de infraestrutura é uma vantagem IMO, principalmente numa linguagem que impõe tanta cerimônia na definição de tipos.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

mochuara wrote:

sergiotaborda wrote:

mochuara wrote:Achei interessante (porque reflete a situação do Java) é que a opção mais simples que é do hashmap é considerado um "esforço".

Existe uma derivação do DTO chamada HashDTO que usa um map para a transferencia. O problema é que isso não é fortemente tipado e leva a um monte de outros problemas.

Ele é fortemente tipado, é um hashmap.

imagine a classe pessoa com nome (String) e data de nascimento (Date). Faça um map tipado para isso.

O melhor que vc vai conseguir é Map<String, Object>

"Object" significa "não sei qual é o tipo".
Existem alternativa que envolvem utilizar metadados que têm que estar presentes dos dois lados.
Funciona, mas dá muito trabalho e como já disse tem problemas.

Não é um tipo específico da sua aplicação, e nem vejo motivo para tal, visto que é apenas para trafegar objetos entre modulos distintos. Não ter que manter código de infraestrutura é uma vantagem IMO, principalmente numa linguagem que impõe tanta cerimônia na definição de tipos.

Na ideia é boa, na prática não é util.

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2030 Offline

oi

não estou me referindo a este value object mas sim ao value object criado pela sun e que depois foi renomeado para DTO.

Vou procurar estudar um pouco sobre o que falou, principalmente sobre esse Fastlane Reader.

Sobre as outras sugestões a minha dúvida fica para quando eu não tenho os frameworks ou então o uso dos metadados fica dificil...

Na verdade nem sei se seria mesmo o VO, mas o que eu queria saber era uma forma de empacotar os dados de uma forma que fosse facil de iterar depois, algo semelhante a uma struct de dados do C.. A minha dúvida é saber se é ruim usar esta classe pessoa com seus gets e sets só para agrupar o retorno do result set ou se tem uma forma melhor de fazer isso..

Tanto em termos de performance como também de manutenção, já que fica difícil quando precisarmos um dia de alterar esta classe ou bean ou sei la se o atributo nome mudar para primeiroNome e ultimoNome..

Neste caso concordo que usar reflection ou metadados vai facilitar bastante..

abs

Notícias, artigos e o maior fórum brasileiro sobre Java