Mais uma duvida sobre DAO

Fala galera, estou aqui de novo precisando do conhecimento de vcs rs. Acontece o seguinte estamos criando classes DAO para o nosso projeto mas entramos num impasse(escrevi certo?) com um outro programador aqui sobre os metodos de acesso ele diz que esses metodos tem q ser staticos. Estaria ele certo?

Para ilustrar qual dos exemplos abaixo é o correto?

Bean utilizado pelas duas classes DAO

public class TesteBean{

private String nome;

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

public void setNome(String parametro){
this.nome = parametro;
}

}

Classe DAO com metodos não estaticos(nesse caso toda vez q for inserir um bean no banco terei de instanciar uma classe DAO)

public class TesteDAO{
public void inserir(TesteBean instancia){
//codigo
}
}

Classe DAO com metodos estaticos, nesse caso não sera necessario instanciar uma classe DAO apenas para inserir um bean no banco.

public class TesteDAO{
public static void inserir(TesteBean instancia){
//codigo
}
}

Entao galera alguem sabe me dizer qual a maneira correta segundo as espeficicações do DAO?Valeu

eu não acho legal fazer estático porque você terá que fazer ele ser synchronized (se houver grande número de acessos ao DAO) e, sendo synchronized, além de poder acessas o método somente um usuário (thread) por vez, ele diminui drasticamente o desempenho

faça um bean normal, faça a instância somente na hora que for usar que não haverá esse problema hehe (mas vai comer mais memória do servidor, pode ter certeza)

bom é o que eu acho

Opa valeu. Eu tb prefiro metodos nao staticos, mas o outro programador acha examente o contrario.

Concordo com o Leozin.

Mas para resolver o impasse.. rsrss.
Faça os testes:
- Monte um DAO com métodos estáticos e outro com não estáticos;
- Faça os testes de tempo, e verá que o desempenho realmente cae, compartilhando a mesma classe para múltiplos acessos.

Relato que, tb passe por esta dúvida e estes testes foram decisivos para obter a melhor solução.

Qual o embasamento dele?

danieldestro wrote:Qual o embasamento dele?

Ele diz que é desnecessario criar uma instancia apenas para inserir um dado, que o metodo seria naturalmente estatico.
Mas me surgiu uma duvida agora.. se eu fizer o DAO com metodo nao estatico e nao sincronizados, como irei impedir q se tente inserir ao mesmo tempo????

Com métodos estáticos você terá problemas se usa recursos compartilhados.

Agora, vou provar como seu amigo perde a razão. Num sistema onde você usa um mecanismo mais, digamos, complexo de DAOs e você quer se aproveitar da OO e das possibilidades que o Java te dá, usar métodos estáticos não dá muito certo.

Exemplo:

Como usar o mecanismo:

Agora, pergunta pro seu amigo se ele faz isso com métodos estáticos de uma maneira elegante?!?!?!?!

Com este mecanismo fica MUITO fácil trocar de JDBC pra Hibernate ou qq outra implementação que você faça, até mesmo híbrido, como eu uso aqui, já que é tudo baseado nas interfaces. Aí é só fazer um mecanismo de configurações e voilá!

danieldestro wrote:Com métodos estáticos você terá problemas se usa recursos compartilhados.

Agora, vou provar como seu amigo perde a razão. Num sistema onde você usa um mecanismo mais, digamos, complexo de DAOs e você quer se aproveitar da OO e das possibilidades que o Java te dá, usar métodos estáticos não dá muito certo.

Agora, pergunta pro seu amigo se ele faz isso com métodos estáticos de uma maneira elegante?!?!?!?!

Com este mecanismo fica MUITO fácil trocar de JDBC pra Hibernate ou qq outra implementação que você faça, até mesmo híbrido, como eu uso aqui, já que é tudo baseado nas interfaces. Aí é só fazer um mecanismo de configurações e voilá!

Eu concordo contigo, valeu pela ajuda. Estou no forum a menos de uma semana e já fui muito ajudado por vcs. Realmente essa comunidade merece a fama que tem

valeu

Métodos estáticos devem ser evitados a todo custo. Eles criam mais problemas do que resolvem.

danieldestro wrote:
Com este mecanismo fica MUITO fácil trocar de JDBC pra Hibernate ou qq outra implementação que você faça, até mesmo híbrido, como eu uso aqui, já que é tudo baseado nas interfaces. Aí é só fazer um mecanismo de configurações e voilá!

Eu uso essa mesma abordagem, mas gostaria de saber como vc faz para fazer esta parte híbrida JDBC + Hibernate. Como não posso mexer no banco e resolvi fazer o modelo de classes mais voltado a OO, acabei ficando com alguns pepinos para fazer a parte hibernate, então uma abordagem híbrida seria o ideal para mim, qq sugestão é bem vinda.

Assim como eu tenho PessoaJdbcDAO, eu posso ter PessoaHibernateDAO. Mas é um OU outro. Mesmo assim você pode misturar os dois ali dentro de uma implementação, sem problemas.

danieldestro wrote:Assim como eu tenho PessoaJdbcDAO, eu posso ter PessoaHibernateDAO. Mas é um OU outro. Mesmo assim você pode misturar os dois ali dentro de uma implementação, sem problemas.

Sim até aí tranquilo.
Mas o seu factory ou cria objetos JDBCDao ou HibernateDao, por isso e é por isso q é fácil mudar entre um e outro é só mudar a factory.
No meu caso eu queria q qdo eu chamasse determinados métodos ele usasse outra factory, qual a melhor maneira de fazer isso, se é viável, ou estou complicado e deveria fazer na mão mesmo.

O motivo para essa complicação, é q eu gostaria q no código mesmo ficasse transparente qual a DAO factory q está sendo usada e em algum lugar eu definiria isso. Depois se eu conseguisse reproduzir com hibernate a mesma performance dos casos mais complexos eu mudaria as configurações e não precisaria mexer no resto.

Se você faz isso, você está amarrando seu negócio com o tipo específico de implementação de DAO. A solução que mostrei justamente desacopla.

No meu caso eu tenho só um DAOFactory. Ele lê de um arquivo qual classe concreta eu uso para cada interface DAO.

Ex:

meu.dao.PessoaDAO=meu.dao.jdbc=PessoaJdbcDAO
meu.dao.XyzDAO=meu.dao.hibernate.XyzHibernateDAO

Humm, entendi, eu interpretei como se vc tivesse vários DAOFactory um para cada forma de persistencia. Você concentra tudo num único DAOFactory q le esses parâmetros e assim ele sabe qual DAO usar (Hibernate ou JDBC, ou etc), é bem isso que eu precisava, estava quebrando a cabeça, ... Valeu.

Ok, métodos estáticos não são a melhor opção porque acabam afetando a estrutura OO do sistema. Metodos estáticos não são métodos soltos no espaço, são métodos que pertencem à classe, não ao objeto.

mAs... o que tem a ver o snchronized? Estático ou não, você teria o mesmo problema.

Notícias, artigos e o maior fórum brasileiro sobre Java