Tava discutindo neste tópico9http://www.guj.com.br/posts/list/23408.java) sobre DTO´s, e fiquei curioso quanto o conceito.
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=Rafael Nunes]Tava discutindo neste tópico9http://www.guj.com.br/posts/list/23408.java) sobre DTO´s, e fiquei curioso quanto o conceito.
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!
Melhor que passar uma collection é passar um array de structs tipados.
ex:
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.
}
}
[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 [/quote]
Na documentação não fala nada sobre getters/setters, diz somente qual a função:
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.
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
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)
Sim , neste caso você só passará os atributos necessários.
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.
Qual o problema de retornar objetos normais, só que apenas com os atributos que você vai usar populados?
Rafael Nunes
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
Suponha que durante um processo eu utilize 30 objetos, não precisam estar necessariamente com todos os atributos preenchidos, mas o necessário para relizar a tarefa. Depois de realizada, eu preciso retornar para a view dos trinta objetos apenas 5 atributos que estão ‘espalhados’ entre eles. Como retornar isso sem ser por uma Collection que reuniria o conteúdo dos 5 atributos?(Aí é que está a dúvida, isso seria um DTO?)
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.
[quote] 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.[/quote]
Creio que não estou me fazendo entender. Agradeço pela resposta, porém minha dúvida não é quando usar, isso eu entendi. Minha dúvida é o que caracteriza um DTO.
Sendo sucinto e conciso:
Retornar um Collection com atributos dos meus objetos de domínio para a view é um DTO?
Pelo que eu entendi uma DTO seria nada mais nada menos que um struct que é passado entre tiers.
um struct seria uma classe sem métodos com apenas atributos a serem populados
ex:
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;
}
}
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.
Oi.
Diz o tio Fowler:
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.
Leiam mais aqui.
Mas o que você acha de implementar um tipo de DTO para cada requisição/retorno ?
Teriamos muitas classes “inuteis”, mas ficaria tudo bem tipado.
Uma DTO generica deixaria a arquitetura muito pobre.
Putz, desisto.
Ou eu sou muito prego e não consegui entender a mensagem subentendida.
Ou eu não estou sabendo me expressar.
Você falou que tem dúvida sobre o que caracteriza um DTO. O Shoes respondeu citando o PoEAA.
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
como o Shoes falou antes qualquer estrutura que vc use para transportar dados entre as camadas da sua app é um dto.
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
Mas pelo q entendi o Shoes não criticou sua utilidade, o DTO tem utilidade mas ainda assim é uma gambiarra…
Por exemplo, o mapeamento Objeto-Relacional é extremamente funcional e útil, talvez não exista solução melhor, mas ainda assim é uma gambiarra.
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. 
Ai vem uma outra grande pergunta. Quantos projetos sao realmente distribuidos que justifiquem o uso de DTO?
]['s
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.