galera
queria saber se tem algum problema eu criar diversos construtores diferentes em um DAO
porque por definição, um JavaBean deve ter apenas um construtor vazio certo? E um DAO é um JavaBean certo?
eu sei que pela parte de implementação isso não tem problema, só queria saber se tem problema na parte de padrões
Java bean não é um DAO !!! Javabeans não classe que possui atributos privados e metódos gets e sets para esse atributos e o DAO - DATA ACCESS OBJECT são classe que fazem a persistência dos objetos de uma classe !!
Bravox
JavaBean == DTO
bom
concluindo então, eu posso ter vários construtores em um DAO certo?
Se realmente for necessário, sim.
Olá
Pera aí, um DTO pode ser um JavaBean mas um JavaBean pode ser também muitas outras coisas.
E também não entendi quando o bravox disse que um DAO não pode ser um JavaBean. Neste abuso que a gente vê por aí do uso dos JavaBeans, acho que já coisas muito mais exóticas como JavaBean.
[]s
Luca
Me corrijam se estiver errado, mas se não me engano, é aconselhavel implementar as classes DAO como Singleton, desta forma e se assim for vc só teria um construtor e que no final das contas vc nem conseguiria chama-lo diretamente (já que seria private).
É isso mesmo colega.
Utilizei o padrão DAO em muitos projetos e acompanhei uma evolução que resultou em um enorme ganho de performance e qualidade dos projetos.
Infelizmente não tenho nenhum fonte aqui comigo, mas o uso do Singleton foi crucial para o sucesso da última versão.
Olá
Por favor explique porque foi importante e porque você gosta tanto dos tão execrados Singletons?
[]s
Luca
http://java.sun.com/products/javabeans/
Mas essa história de JavaBeans ficou muito confusa e ultrapassada já.
No trabalho anterior, onde desenvolvia em JAVA, implementamos a nossa primeira versão do DAO (baseada numa rápida lida nos blueprints da SUN).
Tínhamos uma determinada classe “Chamado” (modelava um chamado técnico). Um objeto dessa classe por sua vez, era composto, entre outros, por objetos do tipo: Tecnico, Localizacao, Problema, Historico (um List).
A cada vez que se fazia necessário manipular chamados era necessário instanciar a fábrica de fábrica DAOs (Abstract Factory), que por sua vez instanciava uma fábrica de DAOs específica para um determinado banco (Factory Method), que por sua vez retornava o DAO específico de chamados para um determinado banco. Lembrando que para um chamado retornar a referência ao técnico, localização, problema etc, seria necessário instanciar a estrutura de DAOs para cada um desses objetos.
Isso causava, a depender do horário, um uso estrapolado de CPU até o estouro de memória (casos mais raros).
Quando refatoramos os código fazendo com que a estrutura DAO fosse um Singleton (entre outras medidas), a coisa fluiu numa performance bem melhor. Hoje o mesmo “servidorzinho” roda outras aplicações utilizadas até por todo o estado de Alagoas sem topar o uso de CPU ou a memória.