Fórum DTO, VO, pra que isso? #568171

O principal objetivo dos DTOs é transportar dados (hum... 'Data Transfer Object'... bem óbvio, não? :)). Pra que isso serve? Em uma aplicação distribuída, é mais performático enviar um objeto com todos os dados necessários, resultado de uma única chamada, do que cada dado individualmente, em várias chamadas. Neste caso, o DTO faz esse papel, consolidado os dados em um único pacote e melhorando a performance. Um outro uso seria separar as camadas lógicas da aplicação, evitando por exemplo a exposição dos objetos de domínio à camada de visualização. Esse uso é um pouco controverso e muitas vezes mal utilizado. Raramente esta escolha é baseada em requisitos reais do sistema. Sobre a 'semelhança' aos Javabeans, as coisas são 'independentes mas relacionadas' :). Javabeans são classes Java comuns que seguem algumas convenções, entre elas os métodos get/set. Como o DTO é basicamente um container de dados, nada mais natural que ele tenha apenas os getters/setters para acessar estes dados. Mas nem todo Javabean é um DTO, e não necessariamente um DTO segue as convenções Javabean. Sobre os nomes, VO, TO e DTO são equivalentes: - Value Object (VO): nome usado na primeira edição do livro Core J2EE Patterns - Transfer Object (TO): nome usado na segunda edição do livro Core J2EE Patterns, já que o nome 'Value Object' já era usado por outros autores para definir um outro conceito. - Data Transfer Object (DTO): nome usado por Martin Fowler, no livro Patterns of Enterprise Application Architecture.

Utilizo Value Object como objetos que são transportados entre as camadas. Uma convenção que aprendi é que o Value Object deve ser o "espelho" de uma tabela do banco, ou quando não, o mais próximo disso. Se temos uma tabela BANCO, com os campos. - idBanco - nomeBanco E a tabela AGENCIA, com os campos. - idAgencia - numeroAgencia - nomeAgencia - idBanco (Foreign Key para a tabela Banco) Devemos representar nossos Value Object assim: BancoVO - Long idBanco; - String nomeBanco; AgenciaVo - Long idAgencia; - Long numeroAgencia; - String nomeAgencia; - BancoVO bancoVO; << referencia para outro ValueObject

Vamos devagar... Sobre nomes, não só o Ronald está certo bem como é altamente desaconselhável falar VO, primeiro pelo padrão Value Object de Martin Fowler/Eric Evans mas até a Oracle tem seu VO, os View Obects do maldito BC4J. Evite-o. Um diagrama ótimo mostrando a função de um DTO está aqui: http://martinfowler.com/eaaCatalog/dataTransferObject.html É como se voc6e zipasse o objeto apra ele ocupar menos espaço. TOs são usados basicamente com Enntity Beans, se você não usa este tipo de EJB provavelmente não precisa deles. Não existe relação direta entre TOs e tabelas. TOs são utilizados para passar dados de Entity Beans para seus clientes. Voltando a JavaBeans, cuidado. JavaBeans é uma especificação de componentes mas hoje em dia fala-se de qualquer coisa que siga a convenção de get/set. UM DTO pode ou não ser um JavaBean e vice-versa. Quanto a MVC, o objeivo básico é ditar a forma que componentes conversam. Ele não necessariamente vai esconder tecnologia e especificamente o dito Model 2 dificilmente o vai.

Agente quebra a cabeça até que as coisas façam sentido, por mais que lhe digam não faça isso, só tem um jeito de aprender... Isso mesmo, vc tem que pôr a mão na massa. Não que eu seja resistente a esses padrões de projeto, realmente desejo trabalhar com eles, é bonito e parece que os benefícios são muitos. Mas conhecendo muito JS, HTML, não tenho probs paracriação de interfaces interessantes. Modelando OO direitinho e sendo a app pequena, sem muita complexidade, usar padrões de projeto, hibernate e struts, torna o trabalho deveras improdutivo. Bom, voltando ao lance das cabeçadas, estou experimentando todas essas coisas misturando-as em doses diferentes. Sei que para muitos VO = DTO mas adaptei as coisas por conta própria e agora estou fazendo assim: VO = mapeamento das tabelas do bd relacional (1 pra 1). DTO = Tbm serializável, encapsula VOs, aproximando da modelagem OO. DAO = Sabem como chegar ao BD. Criam os DTOs. Classes de Neg. = Mantém as regras de negócio, enxergam os DAOs. JSPs = enxergam as Classes de Neg. Será que vai...

Uma coisa que sempre ouvi foi que VO ou DTO serve para simplificar a transferência de dados entre as camadas, porém não vejo muita simplificação na criação de um VO ou DTO para cada tabela, ou classe. Eu utiliozo o conceito de uma forma diferente, criando uma Classe VO, onde nela contém um HashMap de dados e um HashMap de erros. Com isso eu simplificaria realmente essa transferência de dados, passando em todos os métodos do meu sistema apenas uma classe, onde em cada método eu buscaria os dados que são necessários, que estariam no meu HashMap de dados. Não sei se esse é o verdadeiro conceito de VO ou DTO, mas achei uma boa forma de trabalhar. Fernando Rosa

[quote="fernando_generoso"]Uma coisa que sempre ouvi foi que VO ou DTO serve para simplificar a transferência de dados entre as camadas, porém não vejo muita simplificação na criação de um VO ou DTO para cada tabela, ou classe. Eu utiliozo o conceito de uma forma diferente, criando uma Classe VO, onde nela contém um HashMap de dados e um HashMap de erros. Com isso eu simplificaria realmente essa transferência de dados, passando em todos os métodos do meu sistema apenas uma classe, onde em cada método eu buscaria os dados que são necessários, que estariam no meu HashMap de dados. Não sei se esse é o verdadeiro conceito de VO ou DTO, mas achei uma boa forma de trabalhar. Fernando Rosa

DTO ou VO, parece nao existir uma linha que separe os conceitos. O mais importante é adotar um padrão no interfaceamento de camadas e minimizar a clonagem e construcao de novos objetos só para viabilizar o transporte. Isto quando estamos falando de divisão logica pois se tivermos uma divisão fisica do aplicativo entao nao tem como evitar o custo de transporte/serialização. DTO e VO serve para transportar dados. DTO assume um papel mais generalista pois pode ter uma coleção de VOs visando agilizar o transporte de dados. Uma aplicação disto seria num ejb-façade. Um VO por outro lado é o mapeamento de dados para um assunto especifico como por exemplo uma tela do sistema ou uma tabela do banco de dados. O VO pertence a um determinado contexto mais restrito. Exemplificando: numa funcionallidade de cadastro de cliente temos na interface com o usr algumas combo box. Podemos definir um DTO que abrigará todos os elementos necessarios para popular as combos mais uma referencia a VOCliente e usaremos o DTO para comunicar entre o controler (web) com os EJBs. Dentro deste DTO teremos varios arrays de outros VOs, como cidade, estado, etc... e 1 referencia com o VO de cliente. (id,razao, endereco, ...). Numa tela mais simples com codigo e descricao teremos um VO apenas que atuará tambem como DTO em todo o processo de cadastro. Por isto os conceitos se misturam e tambem pq nao difere muito na sua construção. Independente do nome que dermos aos bois, remover qualquer tipo de dependencia com objetos especificos de uma camada é o segredo para a construção destes objetos de dados. Por exemplo, se no seu VO tiver um objeto herdado de java.sql estará limitando o seu transporte (ou criando dependencia desnecearia) para outras camadas do sistema. O cuidado de como transferir a informação é importante tambem. Um java bean pode ser qualqer coisa, depends do contexto, o conceito é mais abstrato ainda.

Poderia eu então no caso de utilização do framework struts, considerar o entitulado "ResultBean" como um DTO? Porque para mim o mesmo só faz este trabalho de levar os dados resultantes das classes de negócio para a view.