Só complementando. No site da sun:
"
Transfer Object Factory Strategy - Transfer Objects and Interfaces:
public interface Contact
extends java.io.Serializable {
public String getFirstName();
public String getLastName();
public String getContactAddress();
public void setFirstName(String firstName);
public void setLastName(String lastName);
public void setContactAddress(String address);
}
public class ContactTO implements Contact {
// member attributes
public String firstName;
public String lastName;
public String contactAddress;
// implement get and set methods per the
// Contact interface here.
…
}
public interface Customer
extends java.io.Serializable {
public String getCustomerName();
public String getCustomerAddress();
public void setCustomerName(String customerName);
public void setCustomerAddress(String
customerAddress);
}
public class CustomerTO implements Customer {
public String customerName;
public String customerAddress;
// implement get and set methods per the
// Customer interface here.
…
}
public class CustomerContactTO implements Customer,
Contact {
public String firstName;
public String lastName;
public String contactAddress;
public String customerName;
public String customerAddress;
// implement get and set methods per the
// Customer and Contact interfaces here.
…
}
"
um DTO é um objeto sem significado no domínio da aplicação, que serve apenas para passar um bandod e dados de um ponto para outro em um ambiente distribuído. É uma gambiarra, bacalhau, etc.
Um JavaBean é um objeto que segue convenções (também gambiarras, IMHO) para acesso de seus atributos.
Nada impede um DTO de ser um JavaBean, mas não é necessário.
O único motivo real apra usar um DTO hoje é suprir a carência numa rede. Se você não produz aplicações distribuídas, se seus objetos estão semrpe no mesmo servidor, usar DTO é uma bela besteira.
[]s
:mad: cada vez mais confuso… o jeito é ser anti-pattern mesmo…
Eu sei… custo de chamadas remotas…
O que eu estava exemplificando é o inverso:nada impede um javabean de ser um dto (normalmente o é).De fato usei mal o termo (dto entre “camadas lógicas”, tsc tsc), é só bean mesmo !
Sobre dto ser gambiarra, concordo em gênero, número e grau, é só pra economia de recursos.
Sobre javabeans, acho até elegante (bom, mas esta realmente é uma opinião pessoal).
Aliás, que solução vocês adotaram para transportar do banco para a view (principalmente naquelas seleções com “200 campos e 50 tabelas” onde não se utilizou framework de persistência) ?
Ahco qeu você quis dizer o contrário… JavaBeans são usado normalmente em muitas cosias diferentes, mas normalment eDTOs são Beans.
O que eu não gosto na especificação é a necessidade de getXX e setXX. O ideal seria eu poder chamar um equivalente a getNome() como nome() apenas, mas eu não imagino como poderia ter as vantagens de um bean sem uma covnençãod e nomenclatura e/ou sem metadata.
[quote=“MHudson”]
Aliás, que solução vocês adotaram para transportar do banco para a view (principalmente naquelas seleções com “200 campos e 50 tabelas” onde não se utilizou framework de persistência) ?[/quote]
Não transporte, transporte seus objetos e faça um lazyloading quando necessário 
[]s
Na verdade era isso mesmo que eu quis dizer, pcalcado (êta efeito tostines). Acho que esta é a grande confusão: se você mapeia cada tabela em uma classe, é um bean, e se os transporta, é dto.
Engraçado, é este encapsulamento que eu gosto. Acho a convenção get e set interessante pois pode-se aplicar alguma lógica a estes métodos quando necessário (atenção, não estou falando de dto).
Sim, com relação ao volume, equaciona-se. Estava falando da quantidade atributos de entidades diferentes sendo agrupados em uma única chamada. No exemplo da Sun, se eu quizer tão somente o nome do cliente (junto com outros 200 atributos de 50 entidades diferentes), como há uma factory, se eu quizer respeitá-la, ou eu passo todos os demais atributos do cliente ou os passo como null.
Calma microfilo, pattern é igual pimenta, sempre arde no início, mas depois que se acostuma a dosar é jóia.
de qq maneira, vc sempre usara DTOs qndo for fazer um DAO, né?
caso constrário, como vc vai mandar teus dados para camada view??
[quote=“microfilo”]de qq maneira, vc sempre usara DTOs qndo for fazer um DAO, né?
[/quote]
Leia o que eu escrevi, você não deve usar DTOs dentrod e um mesmo nó em uma rede, a menos que esteja fazendo algo muito estranho. Você pode usar objetos de negócio no DAO.
[quote=“microfilo”]
caso constrário, como vc vai mandar teus dados para camada view??[/quote]
O que o DAO tem a ver com a apresentação?
a minha ideia de como fazer as coisas é o seguinte:
o DAO acessa o DB, e retorna o resultado em um DTO (javabean ou list de javabean), aí o controller manda o DTO para a camada view… não é isso??
[quote=“microfilo”]a minha ideia de como fazer as coisas é o seguinte:
o DAO acessa o DB, e retorna o resultado em um DTO (javabean ou list de javabean), aí o controller manda o DTO para a camada view… não é isso??[/quote]
Microfilo, DTO != BO.
Vamos combinar uma coisa, se você não estiver trabalhando em um ambiente distribuído, esqueça o termo DTO e pronto!
Os seus DAOs retornam BOs(um BO é um objeto contendo seus relacionamentos que podem ou não estar carregados) e o seu controler envia o so BO para a view.
View0 > Controler > DAO > BOs > View1.
Supomos que no seu modelo você tenha um objeto pessoa, ele possui seus relacionamentos e praticamente a mesma estrutura da tabela pessoa (exceto pelo fato de utilizar referências de objetos à fks). Você recebe um solicitação de consulta de uma determinada pessoa, e através do seu DAO você recupera um objeto pessoa vindo do banco, pronto agora é só enviá-lo diretamente para a view.
:neutral: ta… então é só um emaranhado de nomes O.o…
e se eu to num sistema distribuido?
DTO é um cache???
cada vez mais confuso!!! :tonto:
[quote=“microfilo”]:neutral: ta… então é só um emaranhado de nomes O.o…
e se eu to num sistema distribuido?
DTO é um cache???
cada vez mais confuso!!! :tonto:[/quote]
DTO =! cache
Se você estivesse em um sistema distribuído os DTOs (Data Transfer Objects) seriam utilizados para transportar um conjunto de valores através dos servidores e demais locais da rede.
Esses objetos (burros) seriam úteis para evitar várias chamadas de métodos, por exemplo: um dto poderia levar todos os dados de um cadastro, mesmo que esses dados fizessem partes de entidades diferentes. Então ao receber um DTO o receptor utilizaria o pattern assembler para converter seu DTO em objetos de negócio.
Ex:
Ao passar os dados para o servidor de um cadastro de pessoa, supondo que pessoa e endereço façam parte de entidades diferentes no seu sistema seria muito melhor* passar um único objeto doque vários.
*É claro que esse é um exemplo simples que não teria um impacto significativo na performance, mas parte desse princípio.
:viva: :viva: :viva: :viva: :viva: :viva:
finalmente entendi… valeu volnei!
tem algum IM?
Oooo complicação hein?!
era soh ler a documentação, ela diz exatamente isso.
Mas valeu a discussão, alguns aspectos interessantes foram abordados!
Abraços!
O pessoal tá dizendo que usa DAO com seus BOs. Porque isso então? Seus BO não seriam espertos o suficiente para persistir os próprios dados?
Usar um DAO de dentro do seu BO me faz mais sentido.
[quote=“danieldestro”]
Usar um DAO de dentro do seu BO me faz mais sentido.[/quote]
Você vai acoplar seus objetos de negócio á sua camada de persistência. Vai misturar duas camadas.
Seus objetos de negócio são responsáveis pela lógica de negócios, e não por mapeamento objeto-relacional.
Assim:
((VO == TO) != DTO), certo?
O VO (Value object) é o novo nome de TO (Tranfer Object) certo?
pcalcado,
mas eu falei:
“O VO (Value object) é o novo nome de TO (Tranfer
Object) certo?” e tu respondeste que sim.
Mas olhando:
(http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html),
o Pattern de Transfer Object, ele é o contrário, ou
seja, TO é o novo nome de VO. Mas na Structure ele
trata como VO. Acho que entendi, mas fica difícil pra
quem le a primeira vez…
Rodrigo
