pessoal
o q vcs acham de fazer um projeto MVC, usando os patterns DAO e DTO para a parte de persistencia (MODEL)?
me falaram que é bobagem, que quem faz isso não sabe OO
não entendi pq, para mim é perfeito…
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…
[quote=“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. [/quote]
: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…
[quote=“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…[/quote]
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:
Tenho minha classe (Bean)
[code]public class Pessoa{
long id;
String nome;
String sobrenome;
//gets e sets
}[/code]
e tenho minha interface DAO.
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.
é 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:
A confusão existe porque, geralmente, DTO’s seguem parte da convenção de JavaBeans, mas eles, de maneira alguma são JavaBeans. Outra é que boa parte dos desenvolvedores cria DTO’s e acha que está escrevendo um JavaBean quando, na verdade, estão criando um anemic model (google). BOs deveria ser algo assim:
[code]public class People {
private String name;
private String bla;
…
//set e gets
public boolean save() {
// eu me salvo, mesmo que precise delegar para alguem
}
}[/code]
Ao passo que com modelos burros o codigo fica:
[code]public class People {
private String name;
private String bla;
…
//set e gets
}
// em algum momento…
service.save(people);
[/code]
Em suma, DTO’s não tem regras, não operam sobre si mesmos, enquanto que classes de dominio devem ser capazes de fazer isso.
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 ???