DAO e DTO == Bobagem?

Eu tambem considero bobagem… se você tem seus objetos de negócios bem definidos, porque criar mais um só pra passar dos dados pra DAO?

E se você tem DTOs para tudo, pra que servem seus objetos do modelo?

Eu sempre prefiro passar meus objetos do modelo diretamente para o DAO, pra mim isso é muito mais produtivo.

Oi

:confuso: Pois é, o que um tem haver com o outro? Não entendi…

“Volnei”:

Eu tambem considero bobagem… se você tem seus objetos de negócios bem definidos, porque criar mais um só pra passar dos dados pra DAO?

E se você tem DTOs para tudo, pra que servem seus objetos do modelo?

Eu sempre prefiro passar meus objetos do modelo diretamente para o DAO, pra mim isso é muito mais produtivo.

:joia: eu tb acho isso, nunca nem tentei usar DAO com DTO, mas não deve ser muito bonito não.

T+

Eitcha!!!

Acho q nao to entendendo a discussão… Vamo lá, eu faço meus DTO, e passo o DTO para o DAO gravar… é isso q vc acham bobagem?! Nao to entendendo…

Acho que você está confundindo DTO com DO (Domain Objects)

http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

DTOs foram criados para diminuir o trafego de informações na rede, principalmente o de chamada de métodos. Eles encapsulam os dados em um objeto que é enviado pela rede e ao invés de usar várias chamadas set ou get apenas uma é chamada para o envio do DTO. Não tem nada a ver com BO (DO) DTOs assim como os VOs são utilizados principalmente com os EJBs.

Portanto se não for seu caso, considere seus objetos DOs e não DTOs.

Eu não uso EJB, mas uso DTO com DAO sempre. Acho mais fácil encapsular as informações para que o DAO as persista. Imagine uma tabela com uns 40 campos, sem um DTO para transporte acho o transporte meio complicado. Para o caminho inverso, DAO para DTO, uso um DTO “genérico” que dentre outras coisas, pode ser populado através de um resultset de uma forma bem simples:

DaoGenerico.populate(resultset);

Para recuperá-las:

DaoGenerico.get(“id”);

DaoGenerico.get(“nome”);

O problema é que eu perco a checagem em tempo de compilação, mas o ganho de produtividade compensa (principalmente se como característica de sua aplicação você tem muitos “joins”  de tabelas).

Meus 2 centavos… :roll:

Bom… eu já uso de maneira diferente
haiuehaieha

Tenho meus BO’s, e tenho meus respectivos DAO’s.

utilizo-me de um command intermediário para isso… digamos que eu precise fazer uma inserçao, chama meu command o qual cria um DAO e apartir dai passa o meu objeto BO para o DAO, ou alguma coisa a mais que precise ser feito… digamos, antes de criar chamar o DAO verificar uma certa regra de negocio… bom, dai depende de cada caso =)
mas usar um DTO, ou VO para isso, eu até hoje não vi vantagem quando seu objetos não eh distribuido… pq se fosse distribuido, e vc precisasse fazer um acesso remoto… dai sim, haveria vantagem, e eh justamente pra isso que esses padroes foram feitos…

Ahn… acho que eh isso… nao sei se fui bem claro!

abraços!

Oi

Concordo com o Jujo, se não for distribuído, nao vejo vantagem em usar DTO’s… Aliás, nestes casos, de DTO’s em ambiente não distribuidos, eu prefiro encarar DTO como uma baita de uma gambiarra.

T+

hum

acho que estamos falando de patterns diferentes…

DTO == classe semelhante a JavaBeans?

public class PessoaDTO
{

private String nome;
private int idade;

public String getNome()
{ return this.nome;
}

public int getIdade()
{ return this.idade;
}

//setters
}

é isso, né?

hehehehe

acho melhor vc dar uma estudada melhor nos patterns =)

http://java.sun.com/developer/technicalArticles/J2EE/patterns/

Abraços!

hum… me enganaram! :evil:

eu bem que achei estranho o que o cara da glocal code falou de DTO…

vlw jujo… nunca mais confio em mini-cursos…

"microfilo":

hum... me enganaram! :evil: eu bem que achei estranho o que o cara da glocal code falou de DTO...

vlw jujo... nunca mais confio em mini-cursos...

Agora sim, acho que a confusão foi criada porque você estava confundindo seus BOs com DTOs. Se você deu uma olhada no link que eu passei para o artigo do Mantin Fowler, você verá que é um pouco estranho utilizar o DTO em aplicações não distribuidas.

Suponha que tenho um cadastro simples de pessoa:

public class Pessoa{
  long id;
  String nome;
  String sobrenome;

  //gets e sets
}

public interface PessoaDAO{
  public Pessoa getById(long id);
  public List listAll();
  public int insert(Pessoa pessoa);
  public int update(Pessoa pessoa);
  public int delete(Pessoa pessoa);
}

Pronto, a partir disso eu implemento minhas DAOs que farão o acesso ao banco. Não precisa de DTOs nem VOs trabalha-se apenas com os BOs, mais é normal se confundir afinal são tantos xOs. :wink:

é melhor eu ler o pdf do core j2ee patterns… :oops:

Galera, tô com um nó na cabeça!!!

Ae Volnei, esse exemplo q vc citou, o Seu Bean eh um DTO ou o BO?!?! Se for BO, q q eh um DTO?!?!

vlw…

pois é!

segundo um tutorial do pj, um DTO é uma classe semelhante a um java bean sim

mas tambem pode ser uma classe que extende de uma collection ou map que guarda java beans… :roll:

vcs tão dando um nó na minha cabeça tb…

Aqui diz oque é um DTO e pra que serve…

http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

parece ser exatamente como eu perguntei

Não entendi.
Eles são objetos que geralmente carregam propriedades de várias partes do modelo. No exemplo acima, é utilizado o pattern Assembler para converter um DTO em BOs.

Imagina só você fazendo isso numa aplicação WEB comum, não faz sentido… você não precisa de um DTO para transportar os seus dados o próprio modelo faz isso.
:roll:

public class People {
   private String name;
   private String bla;
   ...
   //set e gets

   public boolean save() {
      // eu me salvo, mesmo que precise delegar para alguem
   }
}

public class People {
   private String name;
   private String bla;
   ...
   //set e gets
}

// em algum momento...
service.save(people);

valeuz...

Agora quem não entendeu fui eu. No exemplo acima , a classe People somente com gets e sets não seria um DTO ?

Se eu, por exemplo, mapeio uma tabela em um javabean e o “transporto” entre camadas, não seria um dto ?
O que eu já de exemplo de bean (construtor vazio, gets e sets) como dto não foi brincadeira. (Ou eu que não entendi mesmo)

Alias: VO=DTO=TO ???

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.

“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) ?

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??

“microfilo”:

de qq maneira, vc sempre usara DTOs qndo for fazer um DAO, né?

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.

“microfilo”:

caso constrário, como vc vai mandar teus dados para camada view??

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??

“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??

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:

“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:

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?

MSN: [email removido]

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.

“danieldestro”:

Usar um DAO de dentro do seu BO me faz mais sentido.

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?

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

A primeira edição (a que tem em português) do J2EE Patterns Catalog fala em VO, a versão online (e imagino que a atual edição americana) mudaram o nome para TO, apesar de manter diagramas antigos como VO, e esse padrão é chamado por Martin Fowler (e é um nome mais genérico) de DTO.

Ahh… estava lendo é imaginando que diabos é este padrão DTO valeu RodrigoW e pacalcado… por me explicar que é a VO…

Se eu estiver equivocado porfavor alguem me corrigia… mas estava sendo discutido que se utilizar VO com DAO, não é muito elegante ??? pq ???

Porque você deve usar DTOs apenas em ambientes altamente distribuídos, não para trocar dados entre camadas, para isso use objetos de domínio.

"jack_-_ganzha":

BOs deveria ser algo assim:

public class People {
   private String name;
   private String bla;
   ...
   //set e gets

   public boolean save() {
      // eu me salvo, mesmo que precise delegar para alguem
   }
}

Ao passo que com modelos burros o codigo fica:

public class People {
   private String name;
   private String bla;
   ...
   //set e gets
}

// em algum momento...
service.save(people);

"pcalcado":

"danieldestro":

Usar um DAO de dentro do seu BO me faz mais sentido.

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.

Se um BO pode ter um método save(), mas não deve acoplar o DAO(segundo pcalcado), como delego a tarefa de salvar para o DAO? Com o 'modelo burro' descrito pelo jack_-_ganzha me parece claro como fazer isso!

Acho que a confusão ocorre em parte pelo excesso de siglas. Nesta lista abaixo todos tem a mesma função:
[list]
VO - Value Object
DTO - Data Transfer Object
TO - Transfer Object
[/list]

Um exemplo:

public class TO {
    private Map data = new HashMap();

    public int getSize() {
        return this.data.size();
    }

    public void setValue(final String key, final Object value) {
        this.data.put(key, value);
    }

    public Object getValue(final String key) {
        return this.data.get(key);
    }

    public void remove(final String key) {
        this.map.remove(key);
    }

}

Estas são as funcionalidades básicas, pode-se acrescentar algumas coisas a mais. A idéia é simplifica o modelo considerando-se beans com muitos parâmetros e muitos getters e setters.

Na definção da Sun, este pattern server para:

Eu particularmente prefiro utilizá-lo assim, de forma genérica mesmo. Sem especializar para ClientVO ou coisa similar.

Para utilizá-lo gosto de usar reflexão para fazer o wrapper entre os tipos quando necessário. Mas normalmente o bean comum já é suficiente para meu uso. Aprendi uma coisa que tem me salvado tempo… Usar a metodologia KISS (Keep It Simple Sucker)

T+