Tenho todos os meus SQL em um arquivo de properties, quando o cliente quer trocar de base de dados eu só faço trocar meu arquivo properties e tudo funciona direitinho.
Ou seja essa solução é ruim ou vcs acham que devo usar o padrão Abstract Factory DAO para isso?
Eu achei essa solução mais rapida para o desenvolvimento e independente de banco de dados. pois se for criar toda estrutura de do patterns Abstract Factory DAO vai acabar na mesma solução dos arquivos properties…que ficara independente de banco de dados.
Na minha humilde opinião, qualquer solução que atenda a necessidade do cliente é válida!
Deve atentá-lo que o Abstract Factory DAO proporciona independencia não só de banco de dados, mas sim da implementação de armazenamento persistente.
Exemplificando, se você um dia quiser que sua aplicação passe a implentar o armazenamento persistente usando Hibernate ou passe a usar outros tipos de repositórios (XML, OODB, etc) sua vida será mais fácil se você implementar o pattern.
Mas sempre temos que ter cuidado com custos e prazos. Se a possibilidade das mudanças acima ocorrerem no projeto for quase nula, não vale a pena mudar sua implementação.
Mas o que te impede de usar as duas técnicas em conjunto?
se vcoê está usando comandos SQL no meio de suas regras de negócio, estejam eles hard-coded ou vindos de um arquivo properties ou qualquer outro lugar, é uma má prática de qualquer jeito.
Tem uma classe chamada ClienteDAO que encapsula todo o acesso a dados.
e no EJB Session Bean uso assim:
ClienteDAO cli=new ClienteDAO();
cli.inserir();
ou seja não estou misturando sql com regra de negocio.
e o patterns DAO faz a aplicação independencia de banco dados…isso eu faço a indepedencia com os arquivos properties. e não preciso fazer toda a hierarquia de classe deste padrão.
Com isso melhoro o tempo de desenvolvimento com toda flexibilidade.
queria opinião de todos…pois essas discursões sempre são validas.
Você quer saber se mantêm o nível de portabildiade no arquivo texto ou em nível de implementação, então? se seu SQL for simples, não tem motivo para você se preocupar em implementar 10000 DAOs diferentes. Mantenha o que tem, como disse a colega.
O importante é você manter interface consistentes, se precisar mudar depois…
não estou utilizando interfaces…só classes ex:
ClienteDAO.java
UsuarioDAO.java
ProdutoDAO.java
e nos Sessionbean instancio eles e uso.
vcs me indicam outra solução?
P.S.: Acho que desse jeito se um dia eu mudar para Hibernate é só substituir o codigo dos metodos de cada DAO e pronto…só modifico na camada de acesso dados.
Sugestões:
[list]
1 - Programe para interface, não implementação
2 - use uma factory (pode ser abstract) para cada um, não complique com Hibernate
[/list]
A idéia do pattern DAO é justamente prover flexibilidade na fonte de dados. Usando somente classes, vc está se amarrando a uma implementação única e específica de DAO. E se vc precisar trocar de fonte de dados de um banco de dados relacional pra, por exemplo, Prevayler?
