http://www.guj.com.br/posts/list/12.java JForum - http://www.jforum.net O que caracterizaria um DTO, uma classe/objeto que seria transportado pelas camadas da aplicação, ou o simples retorno de um método também caracterizaria-se um DTO?
Por exemplo, numa aplicação web, para retornar os dados para uma view, eu executo minhas regras de negócio com meus objetos, e retorno do controller para a view somente uma Collection com as informações/atributos necessários para aquela view. Isso caracteriza um DTO?]]> http://www.guj.com.br/prepost/23552/125730/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125730/dto----duvida-conceitual GMT O que caracterizaria um DTO, uma classe/objeto que seria transportado pelas camadas da aplicação, ou o simples retorno de um método também caracterizaria-se um DTO?
Por exemplo, numa aplicação web, para retornar os dados para uma view, eu executo minhas regras de negócio com meus objetos, e retorno do controller para a view somente uma Collection com as informações/atributos necessários para aquela view. Isso caracteriza um DTO?[/quote]
DTO nada mais seria que um VO.
Ou seja, uma classe com atributos privados que contém gets e sets para acessar os dados indiretamente.
A collection em si não seria um DTO, mas sim a classe utilizada dentro desta collection

Me corrijam se tiver engando!]]> http://www.guj.com.br/prepost/23552/125732/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125732/dto----duvida-conceitual GMT ex:
[code]

class FuncionarioDTO
{
public int codigo;
public String nome;
public String nomeDepartamento;
}

class FuncionarioService
{
public FuncionarioDTO[] consultarFuncionarios()
{
//pode ser array, pois para passar para o client tem que desacoplar do server.
}
}

[/code]

]]> http://www.guj.com.br/prepost/23552/125734/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125734/re-dto----duvida-conceitual GMT Ou seja, uma classe com atributos privados que contém gets e sets para acessar os dados indiretamente.
A collection em si não seria um DTO, mas sim a classe utilizada dentro desta collection [/quote]
Na documentação não fala nada sobre getters/setters, diz somente qual a função:
[i][b]Use a Value Object to encapsulate the business data. A single method call is used to send and retrieve the Value Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Value Object, populate it with its attribute values, and pass it by value to the client.[/b][/i]
Minha dúvida em específico(e bem besta pelo visto) é se um simples método no meu controller retornando uma Collection, caracterizaria um DTO/VO

[quote] Melhor que passar uma collection é passar um array de structs tipados[/quote]

EU discordo, desta forma você teria de ter um VO/DTO pra cada objeto, retornando um array de cada um deles, o que eu estou tentando entender é a forma de retornar os dados para view de uma melhor forma, não fazer gambiarra, mas passar para ela somente o necessário(leia-se não ter de passar 50 objetos com 50 atributos cada e usar só 5 atributos de cada objeto)]]> http://www.guj.com.br/prepost/23552/125753/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125753/re-dto----duvida-conceitual GMT Não é uma cambiarra.
É o que é proposto.
Mas dessa maneira o problema é esse que voce falou.
Eu teria que ter não um DTO para cada objeto, mas sim para cada requisição.
Tem a vantagem de ficar tudo "tipadinho".
Mas a desvantagem de ter muitas classes para fazer muito pouco.

Pelo que vi os conselhos do pessoal, passar coisas muito genericas não fica legal.

Do jeito que você quer teria que ser uma collection de hashMaps.
]]> http://www.guj.com.br/prepost/23552/125757/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125757/re-dto----duvida-conceitual GMT http://www.guj.com.br/prepost/23552/125762/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125762/re-dto----duvida-conceitual GMT
DTO, que quer dizer Data Transfer Object, quer dizer Objeto de tranferência de dados. Mas, para bons programadores, isso não quer dizer exatamente objeto de transferência de dados. Você deve utilizar DTO para resolver o seguinte tipo de problema:

Por exemplo, suponha que vc deverá fazer vários acessos remotos seguidos para realizar uma tranzação distribuída. Então vc primeiro chama um método, ele acessa o servidor remoto, vc chama outro método, ele acessa um servidor remoto, e daí vc faz isso de novo.

O tempo que se gasta fazendo todos estes acessos tem como consequencia uma perda consideravel no tempo de execução da aplicação.

Então, ao invés de ficar transportando uma renca de objetos um de cada vez, vc coloca todos os objetos (ou os dados dele) em uma objeto só, e passa para o servidor. Então vc perde menos tempo com o transporte de dados.

Ao invés de acessar um servidor 3 vezes, vc acessou 1 só. É para isso quer serve um DTO.

Agora Rafael, use somente nestes casos, e nada mais. Não saia inventando DTO pelo seus sitema. O pessoal agui chama esse treco de gambiarra, e realmente é!

Resumo. Use DTO quando vocÊ precisa fazer muitos acessos remotos. Desta forma ao invés de realizar N conexões, vc realizara apenas uma.

Abraços!
Thiago Senna
]]> http://www.guj.com.br/prepost/23552/125776/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125776/re-dto----duvida-conceitual GMT E baseando-me na tua sugestão, eu teria de duplicar meus objetos, setando somente os atributos que eu necessito, ou configurar o que eu não preciso como nulo. Creio que fica um tanto inverossímil retornar cinco objetos quando eu necessito somente de cinco atributos.]]> http://www.guj.com.br/prepost/23552/125777/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125777/re-dto----duvida-conceitual GMT
Resumo. Use DTO quando vocÊ precisa fazer muitos acessos remotos. Desta forma ao invés de realizar N conexões, vc realizara apenas uma.[/quote]

Creio que não estou me fazendo entender. Agradeço pela resposta, porém minha dúvida não é [b]quando[/b] usar, isso eu entendi. Minha dúvida é [b]o que[/b] caracteriza um DTO.

Sendo sucinto e conciso:
Retornar um Collection com atributos dos meus objetos de domínio para a view é um DTO?]]> http://www.guj.com.br/prepost/23552/125779/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125779/re-dto----duvida-conceitual GMT um struct seria uma classe sem métodos com apenas atributos a serem populados
ex:
[code]

class Funcionario
{
private int codigo;
private String nome;
private Departamento departamento;
// getters e setters
}

class Departamento
{
private int codigo;
private String nome;
}

class ConsultaFuncionarioDTO
{
public int codigoFuncionario;
public int codigoDepartamento;
public String nomeFuncionario;
public String nomeDepartamento;
}

class FuncionarioService
{
public ConsultaFuncionarioDTO[] consultarFuncionario()
{
Collection funcionarios = Funcionario.consultar();
ConsultaFuncionarioDTO[] consultaDTO = new ConsultaFuncionarioDTO[funcionarios.size()]

Iterator i = funcionarios.iterator();
for (int index = 0; i.hasNext(); i++)
{
Funcionario func = (Funcionario) i.next();
consultaDTO[index] = new ConsultaFuncionarioDTO();

consultaDTO.codigoFuncionario = funcionario.getCodigo();
consultaDTO.codigoDepartamento = funcionario.getDepartamento().getCodigo();
consultaDTO.nomeFuncionario = funcionario.getNome();
consultaDTO.nomeDepartamento = funcionario.getDepartamento().getNome();

}

return consultaDTO;
}
}

[/code]

Pode parecer tosco, mas se seguirmos ao pé da letra o que é DTO é isso.
Agora se é necessário usar ou não ?
Eu prefiro a ideia do LIPE.
Passe o objeto.
O problema se o objeto for bem modelado ele terá métodos que vão além de simples accessors e interagem na lógica de negócios.
Nestes casos é melhor usar objetos burros para passar dados.
]]> http://www.guj.com.br/prepost/23552/125794/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125794/re-dto----duvida-conceitual GMT
Diz o tio Fowler:

[quote="POEAA"]
Data Transfer Object

An object that carries data between processes in order to reduce the number of method calls.
[/quote]

Ou seja: não importa se tem get, se tem set, se tem coleção, sem coleção, é uma gambiarra por si só. A característica do padrão é empacotar o máximo possível (necessário) para amenizar chamadas RPC.

[quote="POEAA"]
Data Transfer Object is one of those objects our mothers told us never to write. It's often little more than a bunch of fields and the getters and setters for them. The value of this usually hateful beast is that it
result you need to reduce the number of calls, and that means that you need to transfer more data with each d to procall. One way to do this is to use lots of parameters. However, this is often awkwaronly a single value.often impossible with languages such as Java that return The solution Mels How It Works In many ways, amore than a bun
allows you to move several pieces of information over a network in a single call?a trick that's essential for
tributed systems.
[/quote]

Leiam mais [url=http://www.temporeal.com.br/produtos.php?id=168950]aqui[/url].]]> http://www.guj.com.br/prepost/23552/125808/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125808/re-dto----duvida-conceitual GMT Teriamos muitas classes "inuteis", mas ficaria tudo bem tipado.
Uma DTO generica deixaria a arquitetura muito pobre.
]]> http://www.guj.com.br/prepost/23552/125828/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125828/re-dto----duvida-conceitual GMT Ou eu sou muito prego e não consegui entender a mensagem subentendida.
Ou eu não estou sabendo me expressar.
]]> http://www.guj.com.br/prepost/23552/125829/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125829/re-dto----duvida-conceitual GMT [quote] An object that carries data between processes in order to reduce the number of method calls.[/quote]]]> http://www.guj.com.br/prepost/23552/125849/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125849/re-dto----duvida-conceitual GMT
Hummm.. naum... acredito que não!

DTO é uma gambiarra, que tem um monte de atributo e gets e sets. Vc vai usar ele quando vc tem que chamar vários métodos remotos. Mas ao invés de chamar uma renca de metodo remoto, vc cria um método que recebe o DTO e retira os dados de dentro dele, e finalmente recompões os objetos de negócio!

Como vvc tá implementando não importa. Vc pode até retornar uma collection de DTO. As formas de implementações são várias.

Entenda DTO como uma gambiarra que se faz necessário para transmitir uma coleação de informação que podem ser referentes a mais de um objeto de negócio, que quando chega no seu destino ele é utilizado para reconstruir todos os dados dos objetos de negócio.

Abraços!
Thiago]]> http://www.guj.com.br/prepost/23552/125857/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125857/re-dto----duvida-conceitual GMT
so não acho que seja uma gambiarra, todo mundo fala isso, alguns so pq viram no forum.
ele tem sua utilidade em cenarios especificos.
se vc tem sua aplicação distribuida, vai precisar de uma estrutura para transportar os dados.

agora, se existe uma melhor maneira de utilizalos ae ja não sei...

[]'s

]]> http://www.guj.com.br/prepost/23552/125868/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125868/re-dto----duvida-conceitual GMT Por exemplo, o mapeamento Objeto-Relacional é extremamente funcional e útil, talvez não exista solução melhor, mas ainda assim é uma gambiarra. ]]> http://www.guj.com.br/prepost/23552/125909/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/125909/re-dto----duvida-conceitual GMT ]]> http://www.guj.com.br/prepost/23552/126085/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126085/dto----duvida-conceitual GMT [/quote]

Ai vem uma outra grande pergunta. Quantos projetos sao realmente distribuidos que justifiquem o uso de DTO?

]['s]]> http://www.guj.com.br/prepost/23552/126118/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126118/dto----duvida-conceitual GMT Ai vem uma outra grande pergunta. Quantos projetos sao realmente distribuidos que justifiquem o uso de DTO?
[/quote]

Não precisa ser um sistema monstro, mas você está certo no que acho que tentou dizer: 99% dos posts no GUJ sobre isso são sistemas que não precisam de DTOs.]]> http://www.guj.com.br/prepost/23552/126124/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126124/dto----duvida-conceitual GMT
view --> controle --> façade --> negocio --> DTO --> DAO

Fiz diagrama de classes e tudo!!! Achei que eu estava arrasando por que haviam 8 patterns em meu sistema que não tinha tem 10 classes de negócio direito!

Daí eu mostrei para alguns professores, e todos eles me parabenizaram!!
Aff.. Fiquei tão orgolhoso!!!

Abraços!
Thiago]]> http://www.guj.com.br/prepost/23552/126139/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126139/re-dto----duvida-conceitual GMT Antes que me perguntem pq fiz isso... eu digo!

Tinha acabado de ler alguns dos capítulos do livro Core J2ee Patterns!
Imaginem um cabeção e mala que nem eu no 3º ano da faculdade diante de um livro desses! Ele chega a pensar que está no paraíso!

Abraços!
Thiago]]> http://www.guj.com.br/prepost/23552/126141/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126141/re-dto----duvida-conceitual GMT
view --> controle --> DTO --> façade --> negocio --> DAO ]]> http://www.guj.com.br/prepost/23552/126145/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126145/re-dto----duvida-conceitual GMT Ai vem uma outra grande pergunta. Quantos projetos sao realmente distribuidos que justifiquem o uso de DTO?
[/quote]

Não repcisa ser um sistema mosntro, mas você está cerot no que acho que tentou dizer: 99% dos posts no GUJ sorbe isso são sistemas que não precisam de DTOs.[/quote]

Isso, mas digo mais, acho que mais de 90% dos sistemas desenvolvidos em Java nao sao distribuidos.]]> http://www.guj.com.br/prepost/23552/126147/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126147/dto----duvida-conceitual GMT
view --> controle --> DTO --> façade --> negocio --> DAO [/quote]

Porque o DTO esta em uma camada se ele so fica zanzando no sistema?
Existem sistemas onde o DTO é criado na View e vai sendo enviado até o DAO, nao entendo o porque dessa distribuicao demostrada ai.

]['s]]> http://www.guj.com.br/prepost/23552/126148/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126148/re-dto----duvida-conceitual GMT Isso, mas digo mais, acho que mais de 90% dos sistemas desenvolvidos em Java nao sao distribuidos.[/quote]

Eu também. Mais até, bem mais.

Hoje em dia eu trabalho com cluster e clientes remotos, e mesmo assim em uns dois projetos apenas. De resto, nada justificaria um DTO para aplicações web como as que eu já fiz tantas por aí.]]> http://www.guj.com.br/prepost/23552/126150/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126150/dto----duvida-conceitual GMT
E o pessoal confunde e usa DTO para simplesmente para acessar banco de dados, certo? Eu mesmo confundo (ou confundia, sei lá) um pouco, achando que aqueles beans burros que representam as entidades do BD eram DTOs.

Certo???
]]> http://www.guj.com.br/prepost/23552/126153/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126153/dto----duvida-conceitual GMT É tipo "zipar" os dados e mandar de uma vez só, em vez de um a um, certo?
E o pessoal confunde e usa DTO para simplesmente para acessar banco de dados, certo?
[/quote]

Na mosca!

A cosia qeu me dá mis medo quando respondendo alguém aqui ou em alguma lsita é:

[quote="JavaBean Addicted"]
Então, eu tô fazendo meu sistema com camadas, tenho uma Action struts que chama meu [b]AdicionarUsuarioAction[/b], que cria um [b]UsuarioDTO[/b] que passa para meu [b]UsuarioBO]
[/b] que possui um método chamado

public void salvar(String login, string senha);

Que chama meu obejto [b]UsuarioDAO[/b] passando o [b]UsuarioDTO[/b]
...
[/quote]

Onde eles arrumam tanta criatividade?]]> http://www.guj.com.br/prepost/23552/126156/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126156/dto----duvida-conceitual GMT
Na verdade eu tinha feito assim (Podem acreditar.. é sério)

view --> DTO --> controle --> DTO --> façade --> negocio --> DTO --> DAO


[quote=Pensamento do Thiago Senna] Agora o Shoes vai ter um Enfarte!!![/quote]

Abraços!]]> http://www.guj.com.br/prepost/23552/126160/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126160/re-dto----duvida-conceitual GMT
Nao só isso, acho que a maior confusao é com as siglas. DTO, VO, Pojo, Java Beans pra muitos isso é tudo igual e sabemos que isso nao é verdade.
Exemplo, quando o Hibernate diz que precisa de POJO pra persistir os objetos, muitos acham que sao obrigados a usar DTO por isso.

]['s]]> http://www.guj.com.br/prepost/23552/126162/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126162/dto----duvida-conceitual GMT Exemplo, quando o Hibernate diz que precisa de POJO pra persistir os objetos, muitos acham que sao obrigados a usar DTO por isso. [/quote]

Não é somente isso!
Na verdade, temos o costume de pensar que o ideal é contruir um sistema super flexível há mudanças! E muitos pensam que software flexível é sistema enfestado de patterns!
Daí, a falta de experiência fazem com que nós interpretemos estes patterns (DTO) desta maneira.

O problema é que todo mundo quer sistema flexível. O lógico parece ser que um sistema burocrático é o mais ideal para as mudanças, enquanto metodologias ágeis felizmente traz uma outra abordagem, no qual sistemas flexíveis em mudanças são programas com código simples e com bém testado! (resumidamente)

Abraços!]]> http://www.guj.com.br/prepost/23552/126173/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126173/re-dto----duvida-conceitual GMT
E, só para alfinetar:
"Pessoas inventam porcentagens para ganhar credibilidade. 87% das pessoas sabem disso." - Homer Simpson
]]> http://www.guj.com.br/prepost/23552/126175/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/126175/re-dto----duvida-conceitual GMT
Pra mim e (e?) tudo a mesma coisa... leio vc precisa de um (cole aqui uma das sopa de letrinhas supracitada) e no final das contas vejo um JavaBean. Não e pra pensar que e tudo a mesma coisa?

Depois de ler esse topico entendi o que e um DTO (eu acho) e que na verdade nao preciso dele pra p* [piiii] nenhuma.

Agora:
VO = DTO?
Pojo = JavaBean?

Deus me livre!]]> http://www.guj.com.br/prepost/23552/150637/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/150637/dto----duvida-conceitual GMT
Pra mim e (e?) tudo a mesma coisa... leio vc precisa de um (cole aqui uma das sopa de letrinhas supracitada) e no final das contas vejo um JavaBean. Não e pra pensar que e tudo a mesma coisa?

Depois de ler esse topico entendi o que e um DTO (eu acho) e que na verdade nao preciso dele pra p* [piiii] nenhuma.

Agora:
VO = DTO?
Pojo = JavaBean?

Deus me livre![/quote]

Sim.. VO = TO = VO != boas práticas em sistemas não distribuídos!

POJO != Java Bean..

quando se fala de java bean me lembra mais a especicificação de se usar os metodos getAlgumaCoisa, setAlgumaCoisa, isBoolean e por ai vai...

POJO, por sua vez é mais flexível. Pojo nada mais é do que um objeto java simples, sem frescura, sem vaidade, sem batom e sem botox! Se vc vai usar o nome dos métodos igual aos do java bean nele, vc pode fazer isso tranquilamento, assim como muitos fazem! ]]> http://www.guj.com.br/prepost/23552/150654/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/150654/dto----duvida-conceitual GMT quando se fala de java bean me lembra mais a especicificação de se usar os metodos getAlgumaCoisa, setAlgumaCoisa, isBoolean e por ai vai...
[/quote]

Mais que isso, JavaBeans é uma especificação de componentes bem adiantadinha pra sua época, mas que não funfou. O que sobrou dela na maiorida das vezes são frameworks que fazem reflection beaseados em set/Get/Construtor vazio e um ou outro uso de BeanInfo.

Na verdade, essa convenção existe mesmo em C++. Não sei se foi influência de Java (sacrilégio!!!!!), mas que tem tem.]]> http://www.guj.com.br/prepost/23552/150769/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/150769/dto----duvida-conceitual GMT http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs]]> http://www.guj.com.br/prepost/23552/257938/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/257938/redto----duvida-conceitual GMT
Felipe creio que isso não seja uma boa maneira....o bom é ter o seu objeto sempre completo fica meio estranho voce passar um objeto em que voce só tem um dado, se for assim é preferível retornar um array de string....sei lá o o tipo dos seus dados mas nunca o objeto pela metade.....]]> http://www.guj.com.br/prepost/23552/535223/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/535223/re-dto----duvida-conceitual GMT
Felipe creio que isso não seja uma boa maneira....o bom é ter o seu objeto sempre completo fica meio estranho voce passar um objeto em que voce só tem um dado, se for assim é preferível retornar um array de string....sei lá o o tipo dos seus dados mas nunca o objeto pela metade.....[/quote]

hã ?]]> http://www.guj.com.br/prepost/23552/535442/re-dto----duvida-conceitual http://www.guj.com.br/prepost/23552/535442/re-dto----duvida-conceitual GMT [b]
DTO não é um javabeans com getters e setters.
DTO não é o mesmo que um Value Object.
DTO não é um anti-padrão, nem o Fowler falou que DTO é um anti-padrão.[/b]

Recomendo:
(Re)Ler com atenção o que o Shoes, CV e Fowler ([url]http://martinfowler.com/bliki/AnemicDomainModel.html[/url]) escreveram.

E, muito importante...
[url=http://blog.rafaelferreira.net/2007/02/design-patterns-are-not-recipes.html]Padrões não são receitas![/url]



]]> http://www.guj.com.br/prepost/23552/535866/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/535866/redto----duvida-conceitual GMT [quote]
Agora, faço a seguinte pergunta: Eu devo julgar os padrões pela intenção ou pela "implementação" (isto é, a descrição do Padrão no GoF, "obsessivo" por heranças)?[/quote]

[quote=Rafael Ferreira]
Vou deixar o John Vlissides responder essa:
?It seems you can?t overemphasize that a pattern?s Structure diagram is just an example, not a specification. It portrays the implementation we see most often. As such the Structure diagram will probably have a lot in common with your own implementation, but differences are inevitable and actually desirable. At very least you will rename the participants as appropriate for your domain. Vary the implementation trade-offs, and your implementation might start looking a lot different from the Structure diagram.
As for whether one is following the pattern or not, who cares? The pattern is a means to an end, not an end itself. Following it in any strict sense is immaterial. If the pattern solves your problem directly, that?s great; if you have to bend it a bit, that?s great too. Even if the pattern merely inspires you toward an altogether different solution, it has still proven useful. The only potential problem here lies in the documentation phase, when you?re describing your solution in terms of patterns. You don?t want to mislead someone with irrelevant patterns. If you identify a set of classes as adhering to a pattern, make sure they fulfill the pattern?s intent. If the connection is tenuous, don?t mention the pattern; otherwise you?re sure to confuse more than clarify. ?[/quote]]]> http://www.guj.com.br/prepost/23552/535876/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/535876/redto----duvida-conceitual GMT E, muito importante...
[url=http://blog.rafaelferreira.net/2007/02/design-patterns-are-not-recipes.html]Padrões não são receitas![/url]
[/quote]

Essa teria graça se não fosse triste.
Padrões não são receitas de bolo, realmente. Não são "10 passos para a classe maravilhosa". Isso é verdade.
Mas daí a menosprezar os padrões ... peraí ...
Padrões são coisas série. Ou vc segue ou não segue. Mesmo que vc se sinta inspirado, se vc não segue o padrão à risca,
o que vc obtem não é uma implementação do padrão. O detalhes é saber o que é o "padrão à risca" e isso sim é uma coisas metafisica. Mas isso apenas porque os livros de padrões são [u]catálogos [/u]e não teses sobre axiomática.
Vc pode definir os padrões sob a forma de teoremas derivados "matemáticamente" da axiomática de OO. Mas isso seria um texto
chato que 95% das pessoas passaria longe. Com a ideia de que o padrão é uma receita (embora não seja realmente, sim) essas 95% das pessoas pelo menos vão aceitar a ideia.

O que é triste é ter que ler que prototype , mediator e façade são tipos semelhantes de padrões. Essa doeu.
Claro que quem defende que padrões são felxiveis, não são sérios e são meros "guias" dá-se ao luxo de dizer uma coisa dessas.
Para quem acha que padrões são colorários dos axiomas de OO isso equivale a dizer que a operação de soma, divisão e conjugação são tipos semelhantes de operação...]]> http://www.guj.com.br/prepost/23552/536020/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/536020/redto----duvida-conceitual GMT Juro que não entendi a agressividade gratuita.

De qualquer forma, seu argumento vai de encontro à definição de padrão. Se padrões são soluções recorrentes, identificado em situações diferentes... ninguém estava seguindo nada à risca. Nas palavras do fowler: [quote]"One of the interesting things here is that a singular solution can often lead to a recurrent pattern. This usually crops up when you see two different singular solutions which look completely different on the surface, yet have a deeper similarity"[/quote].

Padrões são sérios, e são coisas importantes. Mas é preciso entendê-los e não vê-los como receitas.
Um ótimo exemplo disso é o DTO. O padrão fala do problema de usar vários getters e setters entre sistemas distribuídos. Isso seria muito ruim.... Ao invés disso, sugere-se enviar um objeto que encapsule todas essas informações. Ponto.

O padrão não dita que você não pode colocar código de validação, comportamento, etc nos DTOs.

Outro excelente exemplo é o padrão strategy. Sugiro que as pessoas leiam a descrição do padrão e comparem com a idéia de Interface do Java. Observe que no C/C++ e no Smalltalk não existe Interface... O que você acham? O conjunto List + implementações (ArrayList, LinkedList, etc) não implementa o padrão Strategy? Pattern é isso, uma solução recorrente (um conjunto de melhores práticas) para problemas recorrentes.




]]> http://www.guj.com.br/prepost/23552/536073/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/536073/redto----duvida-conceitual GMT
[b]REFATORAÇAO PARA PADROES
Autor: KERIEVSKY, JOSHUA
Editora: ARTMED
Assunto: INFORMATICA-PROGRAMAÇAO[/b]

O autor aconcelha a ler o livro com a presença de outro livro do Mr. Martin Fowler REFACTORING IMPROVING THE DESIGN OF EXISTING CODE pois ele faz várias referencias sobre este livro.

P.S. O livro é em ingles mas o traduzido está com a qualidade aceitavel, vale a pena dar uma olhada.

Ahhh...já ia esquecendo neste livro não fala de DTO rsrsrsrsr.

flw
]]> http://www.guj.com.br/prepost/23552/536090/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/536090/redto----duvida-conceitual GMT engraçadinho...

Ahhh...já ia esquecendo neste livro não fala de python. hahahahah!


]]> http://www.guj.com.br/prepost/23552/536097/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/536097/redto----duvida-conceitual GMT Juro que não entendi a agressividade gratuita.
[/quote]

Juro que não entendi onde está a agressividade gratuita.

[quote]
De qualquer forma, seu argumento vai de encontro à definição de padrão. Se padrões são soluções recorrentes, identificado em situações diferentes... ninguém estava seguindo nada à risca. Nas palavras do fowler: [quote]"One of the interesting things here is that a singular solution can often lead to a recurrent pattern. This usually crops up when you see two different singular solutions which look completely different on the surface, yet have a deeper similarity"[/quote].
[/quote]

Nas minhas próprias palavras:
"Padrões são colorários dos axiomas de OO"

Eles não aparecem do nada como o Fowler expressa , eles está lá sempre.
Se vc seguir as regras OO ( os axiomas , como SoC, IoC , encapsulamento, etc...) vc tem um código enxuto . Mesmo que vc não saiba os nomes dos padrões que acabou de usar, eles estão lá.
Quando vc identifica uma solução isso não acontece porque vc está notou uma coincidencia, e sim porque vc está vendo as regras funcionarem. Elas funcionam sempre da mesma forma e por isso as "coincidencias" são recorrentes.

[quote]
O padrão não dita que você não pode colocar código de validação, comportamento, etc nos DTOs.
[/quote]

Pois não. Mas regras mais importantes ditam, como o SoC.
O que vc está dizendo é que se eu pegar um pojo da vida o fizer serializable e colocar um monte de codigo de validação, colocar o construtor privado , colocar get/set paras os atributos, 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 eu estarei usando : Prototype (clone copy), Factory-Method (método de criação), TO (serializable) e Bean (get/set).
Não. Vc está fazendo apenas uma salada de frutinhas e pior, violando o SoC.
Em suma, se viola o SoC o seu codigo não pode ser considerado bom, muito menos um padrão.

[quote]
Outro excelente exemplo é o padrão strategy. Sugiro que as pessoas leiam a descrição do padrão e comparem com a idéia de Interface do Java. Observe que no C/C++ e no Smalltalk não existe Interface... O que você acham? O conjunto List + implementações (ArrayList, LinkedList, etc) não implementa o padrão Strategy?
[/quote]

Interfaces são constutos uteis ao padrão strategy, mas não são a "implementação do padrão strategy" isso é absurdo. Strategy pode ser feito com herança normal se não existissem interfaces.
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.

Como os texto que citou falam : padrão é algo que não existe na linguagem. É algo que vc [u]faz com[/u] a linguagem.

[quote]
Pattern é isso, uma solução recorrente (um conjunto de melhores práticas) para problemas recorrentes.
[/quote]

Padrões não são conjuntos de melhores práticas, são o resultado direto do seguimento coerente dos principios de OO. Quando vc aplica os principios de OO a um problema vc obtem um resultado. Se aplicar de novo os mesmos princípios vc obtem o mesmo resultado. A aplicação dos principios é complexa, por isso vc pula essa fase. Dai quand vc tem um problema vc tem a solução. Mas ela não aparece magicamente.

Um exemplo, a lei de pitagoras para a relação entre os catetos e a hipotenusa de um triangulo retangulo pode ser usada diretamente sem ter que a deduzir a todo o momento. O mesmo que a as leis de newton.
Ou seja, se vc tem um problema vc aplica o que já sabe e obtem um resultado. Vc não perde tempo deduzindo a solução a partir de principios básicos cada vez que tem um problema. Da mesma forma vc não deduz a solução para um problema de OO a cada vez que precisa, vc faz isso as primeiras vezes e depois vc já sabe a solução e aplica. Vc cataloga as soluções para fácil uso e pronto.
As solução advem dos principios. Os padrões são atalhos. Dado um problema o padrão dá a solução. Mas o padrão contêm em si todo o processo de aplicação dos princípios da OO.

Padrão não são receitas de bolo, mas são mais que guias: são corolários. Ou seja, não é possivel, para o mesmo problema encontrar outra solução diferente. Se fosse guias ou receitas poderiam ser encontradas outras formas.

O que temos diferente são as implementações. Ai sim, existem muitas variantes. Mas o padrão não inclui a implementação, por isso a variedade de implementações não afeta em nada a realidade de que o padrão é univocamente definido pelo problema e pela aplicação dos axiomas de OO.



[/quote]]]> http://www.guj.com.br/prepost/23552/536194/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/536194/redto----duvida-conceitual GMT
Eu enfatizo que o conceito do padrão é mais importante que a estrutura. Veja:

[quote]O que vc está dizendo é que se eu pegar um pojo da vida o fizer serializable[/quote]
ok

[quote]e colocar um monte de codigo de validação,[/quote]
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.

[quote]colocar o construtor privado,[/quote]
Huh(vamos ver...)

[quote]colocar get/set paras os atributos, [/quote]
ok

[quote]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[/quote]
Ops...

[quote] eu estarei usando : Prototype (clone copy),[/quote]
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.

[quote]Factory-Method (método de criação),[/quote]
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.

[quote] TO (serializable) [/quote]
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.

[quote]e Bean (get/set). [/quote]
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:

[quote]
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.
[/quote]

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.

[quote]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. [/quote]
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.


]]> http://www.guj.com.br/prepost/23552/536506/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/536506/redto----duvida-conceitual GMT [quote] TO (serializable) [/quote]
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.

[quote]e Bean (get/set). [/quote]
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:
[/quote]


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 [url=http://sergiotaborda.wordpress.com/java/patterns/bean/]bean[/url]. 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.



[quote]
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.
[/quote]

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)]]> http://www.guj.com.br/prepost/23552/536600/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/536600/redto----duvida-conceitual GMT 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.

[quote]Eu não falei em javabean eu falei em bean. [/quote]
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.


[quote]
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. (...)
[/quote]
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 [b]"Estrutura"[/b]: 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.

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


]]> http://www.guj.com.br/prepost/23552/536646/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/536646/redto----duvida-conceitual GMT
[quote]
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. (...)
[/quote]
Eu não diria que esta essa é a demonstração mais formal que conheço.
[/quote]

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

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

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.

[quote]
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.
[/quote]

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.)]]> http://www.guj.com.br/prepost/23552/536825/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/536825/redto----duvida-conceitual GMT
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

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

list.add(p);
}[/code]

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 [i]Our solution[/i] ele diz

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

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

O que vocês costumam fazer? Ou usam o [i]VO[/i] Pessoa mesmo?? ]]> http://www.guj.com.br/prepost/23552/788088/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/788088/redto----duvida-conceitual GMT [/quote]

a minha duvida tem a ver com a frase acima tb, no caso que eu coloquei não tenho uma aplicação distribuida ...]]> http://www.guj.com.br/prepost/23552/788093/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/788093/dto----duvida-conceitual GMT
Como que é sua aplicação?

É client x server?


flws
]]> http://www.guj.com.br/prepost/23552/788202/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/788202/redto----duvida-conceitual GMT http://www.guj.com.br/prepost/23552/788215/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/788215/redto----duvida-conceitual GMT
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

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

list.add(p);
}[/code]

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 [i]Our solution[/i] ele diz

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

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

O que vocês costumam fazer? Ou usam o [i]VO[/i] Pessoa mesmo?? [/quote]

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.

]]> http://www.guj.com.br/prepost/23552/788221/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/788221/redto----duvida-conceitual GMT
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. [/quote]

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

flws
]]> http://www.guj.com.br/prepost/23552/788243/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/788243/redto----duvida-conceitual GMT ]]> http://www.guj.com.br/prepost/23552/788308/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/788308/redto----duvida-conceitual GMT [/quote]

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. ]]> http://www.guj.com.br/prepost/23552/788406/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/788406/redto----duvida-conceitual GMT [/quote]

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. [/quote]

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.]]> http://www.guj.com.br/prepost/23552/788417/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/788417/redto----duvida-conceitual GMT [/quote]

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. [/quote]

Ele é fortemente tipado, é um hashmap.
[/quote]

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.

[quote]
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.[/quote]

Na ideia é boa, na prática não é util.]]> http://www.guj.com.br/prepost/23552/788711/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/788711/redto----duvida-conceitual GMT
não estou me referindo a este [url=http://c2.com/cgi/wiki?ValueObject]value object[/url] 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]]> http://www.guj.com.br/prepost/23552/788817/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/788817/redto----duvida-conceitual GMT 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.

[/quote]

wow.. Voce consegue transformar ate o problema mais simples (fazer um conjunto de dados aparecer em outro ponto do sistema seja por cópia ou referência) numa questão digna de merecer a "melhor solução" que precisa de novos tipos, abstrações, frameworks, etc.

Detalhe, o objetivo inicial era claro no sentido de ser a solução mais simples....

mas voce pode justificar soluções complexas e apontar os perigos decorrente de uma solução mais simples, mas que tipo de bolha vc vive pra achar que isso é um campeonatinho de quem oferece a solução mais sofisticada? No mundo real o BOM programador precisa ser capaz de escolher quais os problemas que realmente valem a pena perder seu tempo. Talvez a empresa que o outro colega ai trabalha seja líder de vendas no mercado de frameworks de transferencia de objetos ou então se trata de um projeto opensource (que é hobby e não da precisa gerar dinheiro pro seu chefe), se não for este o caso...]]> http://www.guj.com.br/prepost/23552/789062/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/789062/redto----duvida-conceitual GMT 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.

[/quote]

wow.. Voce consegue transformar ate o problema mais simples (fazer um conjunto de dados aparecer em outro ponto do sistema seja por cópia ou referência) numa questão digna de merecer a "melhor solução" que precisa de novos tipos, abstrações, frameworks, etc.

Detalhe, o objetivo inicial era claro no sentido de ser a solução mais simples....

mas voce pode justificar soluções complexas e apontar os perigos decorrente de uma solução mais simples, mas que tipo de bolha vc vive pra achar que isso é um campeonatinho de quem oferece a solução mais sofisticada? No mundo real o BOM programador precisa ser capaz de escolher quais os problemas que realmente valem a pena perder seu tempo. Talvez a empresa que o outro colega ai trabalha seja líder de vendas no mercado de frameworks de transferencia de objetos ou então se trata de um projeto opensource (que é hobby e não da precisa gerar dinheiro pro seu chefe), se não for este o caso...[/quote]

não sei em que dimensão vc vive, mas na minha dimensão HashDTO é um anti-pattern. Não só ele é , como eu já tive as mesmas ideias que vc está colocando e já as implementei e já vi que tem problemas práticos. Como já disse, funciona, mas tem problemas.
O principal problema é a tipagem fraca. O fato de não usar um bean o impede de interagir facilmente com outro frameworks como o hibernate e outros. HashDTO parece uma solução simples, mas não é. Estou lhe dizendo isto como um fato porque eu já usei. não se trata de procura a melhor solução, trata-se de - na minha dimensão - eu já ter experimentado essa solução e ter visto com os meus olhos que não é prática. A infra é simples, mas o uso é complexo.

A unica forma util de usar HashDTO é transformando de bean para map e vice versa usando o HDTO apenas na comunicação.
Mas vai dai isso obriga a ter a classe do bena original dos dois lados e isso significa que não precisa do HahsDTO pode simplesmente usar a classe do bean.

Na minha dimensão as pessoas têm experiencia com as coisas e as pessoas que não têm essa experiencia agradecem que as pessoas que a têm partilhem as suas conclusões. não só isso, como - na minha dimensão - existe a internet e existe centenas de pessoas contando suas experiencia. Na minha dimensão - que eu chamo de mundo real também - ser um bom programador não significa saber tomar decisões sobre design patterns e o problema dos objetos distribuídos não é simples. ]]> http://www.guj.com.br/prepost/23552/789130/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/789130/redto----duvida-conceitual GMT não sei em que dimensão vc vive, mas na minha dimensão HashDTO é um anti-pattern. Não só ele é , como eu já tive as mesmas ideias que vc está colocando e já as implementei e já vi que tem problemas práticos. Como já disse, funciona, mas tem problemas.
O principal problema é a tipagem fraca. O fato de não usar um bean o impede de interagir facilmente com outro frameworks como o hibernate e outros. HashDTO parece uma solução simples, mas não é. Estou lhe dizendo isto como um fato porque eu já usei. não se trata de procura a melhor solução, trata-se de - na minha dimensão - eu já ter experimentado essa solução e ter visto com os meus olhos que não é prática. A infra é simples, mas o uso é complexo.

A unica forma util de usar HashDTO é transformando de bean para map e vice versa usando o HDTO apenas na comunicação.
Mas vai dai isso obriga a ter a classe do bena original dos dois lados e isso significa que não precisa do HahsDTO pode simplesmente usar a classe do bean.

Na minha dimensão as pessoas têm experiencia com as coisas e as pessoas que não têm essa experiencia agradecem que as pessoas que a têm partilhem as suas conclusões. não só isso, como - na minha dimensão - existe a internet e existe centenas de pessoas contando suas experiencia. Na minha dimensão - que eu chamo de mundo real também - ser um bom programador não significa saber tomar decisões sobre design patterns e o problema dos objetos distribuídos não é simples. [/quote]

Acontece que -na dimensão do post que ressucitou o tópico- não se trata de sistema distribuido e nem foi mencionado que vai usar hibernate. Ainda assim vc continua sustentando o mesmo argumento? ]]> http://www.guj.com.br/prepost/23552/789135/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/789135/redto----duvida-conceitual GMT Acontece que -na dimensão do post que ressucitou o tópico- não se trata de sistema distribuido e nem foi mencionado que vai usar hibernate. Ainda assim vc continua sustentando o mesmo argumento? [/quote]

Sim. Se estamos falando de um sistema local então nem ha porque falar em DTO para começo de conversa. Logo, usar HashDTO seria a exarcebação do erro.

Você pode estar confundindo com objeto de contexto (Context Object) em que o map funciona perfeitamente. Este tipo de objeto é passado e repassado várias vezes , mas tecnicamente ele não é um DTO. Exemplos classicos são o request, o response e o session da servlet api.]]> http://www.guj.com.br/prepost/23552/789225/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/789225/redto----duvida-conceitual GMT Acontece que -na dimensão do post que ressucitou o tópico- não se trata de sistema distribuido e nem foi mencionado que vai usar hibernate. Ainda assim vc continua sustentando o mesmo argumento? [/quote]

Sim. Se estamos falando de um sistema local então nem ha porque falar em DTO para começo de conversa. Logo, usar HashDTO seria a exarcebação do erro. [/quote]

Pirou de vez? Quem falou de DTO, hashDTO, HBO... foi vc!!!

[quote=sergiotaborda]
Você pode estar confundindo com objeto de contexto (Context Object) em que o map funciona perfeitamente. Este tipo de objeto é passado e repassado várias vezes , mas tecnicamente ele não é um DTO. Exemplos classicos são o request, o response e o session da servlet api.[/quote]

Eu confundi? Bom, pelo menos vc teve um momento de lucidez finalmente, é por ai mesmo. Eu não chamaria de DTO tb, chamaria de.. advinha, um map.

]]> http://www.guj.com.br/prepost/23552/789326/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/789326/redto----duvida-conceitual GMT Acontece que -na dimensão do post que ressucitou o tópico- não se trata de sistema distribuido e nem foi mencionado que vai usar hibernate. Ainda assim vc continua sustentando o mesmo argumento? [/quote]

Sim. Se estamos falando de um sistema local então nem ha porque falar em DTO para começo de conversa. Logo, usar HashDTO seria a exarcebação do erro. [/quote]

Pirou de vez? Quem falou de DTO, hashDTO, HBO... foi vc!!!
[/quote]



Titulo do topico : "[b]DTO [/b]- duvida conceitual"

Citação do André Fonseca que reiniciou o topico :"Lendo algumas referências, inclusive muitas apresentadas aqui, consigo entender o que é o [b]DTO [/b] e quando usar. "

Eu falei em DTO porque[u] esse é o tema do topico[/u]!

EoM
]]> http://www.guj.com.br/prepost/23552/789384/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/789384/redto----duvida-conceitual GMT Eu falei em DTO porque[u] esse é o tema do topico[/u]!
[/quote]

Então vc respondeu pra pessoa errada porque eu não falei de DTO, mas sim de usar um map.

[quote=sergiotaborda]Se estamos falando de um sistema local então nem ha porque falar em DTO para começo de conversa. Logo, usar HashDTO seria a exarcebação do erro.

[b]Você[/b] pode estar confundindo com blablabla...[/quote]

A semântica de um map é completamente diferente de um DTO, porque não reconhece que esta viajando na maionese desde o início porque o sistema é local e vc continua falando em DTO, hashDTO (seja la que porra é essa). ]]> http://www.guj.com.br/prepost/23552/789416/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/789416/redto----duvida-conceitual GMT
acho que talvez o motivo da confusão foi a forma de eu expressar a minha dúvida

o que eu queria saber é qual a melhor forma de se criar uma lista com o retorno de um result set de tal forma que seja fácil iterar nesta lista no meu cliente - camada que vai usar esta lista

o que se costuma fazer é criar um objeto burro com apenas estado e criar uma lista com estes objetos

talvez este saco de atributos tenha mesmo mais a ver com o outro VO que mencionei acima do que o DTO que é o antigo VO renomeado pela SUN, e que na verdade surgiu para resolver o problema de trafegar objetos em rede em sistemas distribuidos..

a minha dúvida teria mais a ver com: isso é considerado uma quebra do paradigma OO? isso é uma má pratica? afeta performance? teria uma forma mais customizavel de se fazer isso? ( para o caso dos atributos desses sacos de atributos mudarem??)

resumindo, acho que confundi mesmo o atual VO com o DTO...]]> http://www.guj.com.br/prepost/23552/789654/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/789654/redto----duvida-conceitual GMT
acho que talvez o motivo da confusão foi a forma de eu expressar a minha dúvida

o que eu queria saber é qual a melhor forma de se criar uma lista com o retorno de um result set de tal forma que seja fácil iterar nesta lista no meu cliente - camada que vai usar esta lista

o que se costuma fazer é criar um objeto burro com apenas estado e criar uma lista com estes objetos

(..)
a minha dúvida teria mais a ver com: isso é considerado uma quebra do paradigma OO? isso é uma má pratica? afeta performance? teria uma forma mais customizavel de se fazer isso? ( para o caso dos atributos desses sacos de atributos mudarem??)

[/quote]

Vamos esclarecer a nomenclatura. Se você tem um sistema orientado a dados vc traduz linhas de banco em [url=http://www.javabuilding.com/pattern/property-bag.html]PropertyBags[/url]. Estes objetos são burros. (Veja que o proprio ResultSet é um ProeprtyBag neste sentido)
Se vc traduz cada linha num sistema orientado a entidades vc traduz para uma instância de uma entidade. Estas classes têm logicas além de get/set. por exemplo, logicas de estado num método "isActive()" que é true se o campo XTPO não é nulo, por exemplo.

Vc tem PropertyBags ou entidades ?
A entidades podem ser cross-layer. Podem. Não têm que ser.

Agora vc precisa passar uma coleção desses objetos para outra camada.

Nessa outra camada o objeto tem as mesmas propriedades ?

Na camada de apresentação é comum necessitar de mais dados do que aqueles que estão na entidade/bag original para controle da propria apresentação. Neste caso é licito implementar objetos especiais da camada. O Core JEE chama a isto ViewHelpers, mas seria mais como entidades da camada de apresentação. quando a entidade do dominio é cross-layer ela é usada tb como entidade da camada de apresentação. É comum carregar um list passar o jsp e usar um c:forEach para iterar e usar os proprios campos para ler e escrever os valores. Mas as vezes não funciona.

no struts 1 por exemplo, as actionforms são objetos populados da tela e para a tela. Vc tem que traduzir suas entidades de dominio para esses objetos. Esses objetos são "view entitys".

Se vc usa PropertyBag no sistema , mais uma ou menos uma propriedade não muda nada, mas se usa entidades é bem provável que precise convertê-las para PropertyBag em algum ponto ( trasnferencia para outro nodo, persistencia, exportação/inportação , webservices e display, são as mais comuns). Sobretudo se esse ponto é na fronteira do sistema.

Não ha nenhuma quebra de OO se as responsabilidades forem bem entendidas e separadas. Na realidade vc usa isso todos os dias, vc só não presta atenção ( O Hibernate transforma as entidades num objeto intermédio que é como um array de colunas com valores. Vc não vê, mas ele está usando essa mesma logica que vc está falando.]]> http://www.guj.com.br/prepost/23552/789830/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/789830/redto----duvida-conceitual GMT
Entendi do que foi dito que na verdade o meu sistema precisa de uma lista de Property Bags e não Entidades.

Agora, quanto ao fato desses objetos mudarem com o tempo? Qual seria uma forma que facilitaria a customização?

Por exemplo,

O meu objeto Pessoa mudou sua propriedade de

[code]String nome;[/code]

para

[code]String primeiroNome;
String sobreNome;
[/code]

Como refletir estas mudanças em todas as camadas que utilizam listas deste objeto? Seria introspecção uma boa forma? (java beans) Você teria um exemplo de como fazer isso com um Map que fosse de fácil alteração depois?? (Supondo que eu não tenha propriedades tipadas)]]> http://www.guj.com.br/prepost/23552/790585/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/790585/redto----duvida-conceitual GMT
Entendi do que foi dito que na verdade o meu sistema precisa de uma lista de Property Bags e não Entidades.

Agora, quanto ao fato desses objetos mudarem com o tempo? Qual seria uma forma que facilitaria a customização?

Por exemplo,

O meu objeto Pessoa mudou sua propriedade de

[code]String nome;[/code]

para

[code]String primeiroNome;
String sobreNome;
[/code]

Como refletir estas mudanças em todas as camadas que utilizam listas deste objeto? Seria introspecção uma boa forma? (java beans) Você teria um exemplo de como fazer isso com um Map que fosse de fácil alteração depois?? (Supondo que eu não tenha propriedades tipadas)[/quote]

com map não dá para usar como vc quer. As keys dos maps não são interpretadas por nenhuma IDE como propriedades. Logo, vc teria que fazer esse refactoring na mão e ai vc se estrepa.
Ai vc usa beans com seus set/get e reflection. Existem bibliotecas que ajudam a fazer isso se vc não quiser fazer na mão.

Com isso vc ganha não só tipagem forte para cada campo mas tb facilidade de refactoring que é muito mais importante ainda.

Usar map para isso não é uma boa(esse era o ponto em relação ao HashDTO), vc vai se arrepender logo na primeira vez que precisar trocar o nome de algum campo.]]> http://www.guj.com.br/prepost/23552/790831/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/790831/redto----duvida-conceitual GMT Agora, quanto ao fato desses objetos mudarem com o tempo? Qual seria uma forma que facilitaria a customização?

Por exemplo,

O meu objeto Pessoa mudou sua propriedade de

[code]String nome;[/code]

para

[code]String primeiroNome;
String sobreNome;
[/code]

Como refletir estas mudanças em todas as camadas que utilizam listas deste objeto? Seria introspecção uma boa forma? (java beans) Você teria um exemplo de como fazer isso com um Map que fosse de fácil alteração depois?? (Supondo que eu não tenha propriedades tipadas)[/quote]

Assumindo que vc preferiu estender um map ao invés de criar um wrapper, ficaria assim:

pessoa.remove("nome");
pessoa.put("primeiroNome", "André");
pessoa.put("sobreNome", "Fonseca");

Caso não queira fazer na mão pode passar o "trabalho" para um estagiário. Tudo que ele precisa fazer é ler o javadoc do hashmap.]]> http://www.guj.com.br/prepost/23552/791236/redto----duvida-conceitual http://www.guj.com.br/prepost/23552/791236/redto----duvida-conceitual GMT http://www.guj.com.br/prepost/23552/791241/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/791241/dto----duvida-conceitual GMT
Isso é uma pergunta ou uma afirmação ?
Se for uma pergunta a resposta é: a diferença é historica.

Historicamente os nomes Value Object e Transfer Object significavam a mesma coisa. è um objeto "burro" serializável que permite passar dados entre nodos. Eram padrões do J2EE Core patterns

Ai veio o Martin Fowler e utilizou o nome Value Object para se referir a um outro tipo de padrão. Então o nome Value Object e VO passaram a significar isso, e ele criou o nome DTO para significar o que TO significava.

A segunda edição do core jee patterns aboliu o uso de VO no sentido antigo e deixo o nome [url=http://java.sun.com/blueprints/patterns/TransferObject.html] Transfer Object[/url] (que é mais genérico que Data Transfer Object) para signifca o objeto burro serializável.

Ai para evitar confusão o temo DTO foi abandonado (embora significa o mesmo que TO) e apenas os termos Value Object - significando o padrão do Fowler e TO significando o padrão do core j2ee paterns ficaram.

Hoje em dia se vc se referir ao objeto burro serializável como "VO" vc estará indicando que não está atualizado e tudo o que deriva dai.

]]> http://www.guj.com.br/prepost/23552/791352/dto----duvida-conceitual http://www.guj.com.br/prepost/23552/791352/dto----duvida-conceitual GMT