DTO - dúvida conceitual

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?

Rafael Nunes wrote: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?

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!

This message was edited 1 time. Last update was at 28/04/2005 09:35:08

Melhor que passar uma collection é passar um array de structs tipados.
ex:

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

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

Melhor que passar uma collection é passar um array de structs tipados

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)

This message was edited 1 time. Last update was at 28/04/2005 10:04:24

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.

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Qual o problema de retornar objetos normais, só que apenas com os atributos que você vai usar populados?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

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.

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.

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?

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

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:

POEAA wrote:
Data Transfer Object

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

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.

POEAA wrote:
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.

Leiam mais aqui.

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

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.

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Você falou que tem dúvida sobre o que caracteriza um DTO. O Shoes respondeu citando o PoEAA.

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

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Rafael wrote: Retornar um Collection com atributos dos meus objetos de domínio para a view é um DTO?

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

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