Estou utilizando DAO como pattern de acesso a bases de dados
(usando também hibernate).
Gostaria de saber a opinião de vocês.
Quando eu crio a classe abstrata DAOFactory, eu defino
diversos métodos abstratos especificos para um determinado projeto,
como por exemplo:
public abstract CustomerDAO getCustomerDAO();
Então eu extendo esta classe (Ex.: GenericDAOFactory).
Fazendo desta maneira, eu não deixo muito expecifico esta camada
para um determinado projeto que utilize a classe Customer, por ex???
Pois eu poderia criar diversas classes para acessar a base de dados,
e criar um JAR para estes e utilizar em qualquer projeto.
Usando desta maneira, toda vez que eu tiver que desenvolver um
novo projeto, eu terei que mudar a classe abstrata
DAOFactory e GenericDAOFactory.
É claro que eu ganho muito em relação a poder utilizar diversos
gerenciadores de bancos de dados, mas, provalmente, quando eu
mudar de projetos, que utilizam outras classes, terei que mudar
as classes acima.
Bom, estou começando agora com isso, posso estar enganado
em relação a algumas coisas, então gostaria de saber
as opiniões de vocês sobre este importante assunto.
Acredite ,sempre vale a pena usar uma pattern
eu uso DAO a um bom tempo ,junto com trasnfer objects
de uma olhada nesse link que você vai ver diversos padrões de projetos de J2EE
No caso eu montei um classe chamada DataSource (que usa Hibernate), que abstrai todo o acesso a base de dados.
E se eu quiser o modo de acesso (tenho uma outra classe que
usa as querys que estão em diversos arquivos xml) eu mudo
no DAOFactory e nos <Object>DAO, não precisando mudar nada
os Objetos de negócio, mantendo a mesma estrutura DAO já definida.
É exatamente assim que eu uso o DAO. Ele apenas acessa o banco de alguma maneira e guarda as informações sem nenhuma logica de negocio. Assim vc abstrai completamente para as classes que possuem as regras como os dados são guardados. Pode usar um banco, arquivos, sei lá mais o que. Só que geralmente não uso factory junto como o DAO. Qual a utilidade disso?
Acredito que um dos motivos da factory é que vc pode ter, por exemplo, três tipos de classes dao (acessando banco, acessando um arquivo xml e acessando, sei lá, um sistema legado) quem escolhe a classe que será usada é a factory… Assim se for criado um DAO acessando alguma outra coisa (um LDAP, por exemplo) para o seu sistema funcionar bastará trabalhar com a factory…
Acho q entendi o esquema de Factory.
então, acho q não vou precisar usar factories, pois estou usando o
Hibernate, que utiliza diversos bancos de dados, Não precisando
que o factory escolha qual banco utilizar, pois o hibernate se encarrega
disso.
Ta aí uma coisa que vc disse que é verdade.
É bem complicado mesmo fazer factory, isso é!!! hehehe
Mas vale muito pela experiência e por estes novos conhecimentos
adquiridos…
Valew a pena mesmo assim…
Factory Method: Quando o armazenamento NÃO estiver sujeito a alterações de uma implementação para outra.
Abstract Factory: Quando o armazenamento estiver sujeito a alterações de uma implementação para outra. Neste caso é que pode ter
diversos esquemas de armazenamento (Oracle, sqlserver, etc).
Se eu entendi direito, de acordo com isto que eu achei,
O factories podem ou não usar diversas implementações de armazenamento diferentes.
Então factories seriam “fábricas” de conexões com DBs, abstraindo
estes DBs???
Nesse seu caso é isso mesmo, entretanto vc pode ter factories para qualquer objeto. Não apenas para um acesso a banco…
A interessante ressaltar que o DAO não serve unicamente para acesso a banco, pode por exemplo servir para armazenar em um arquivo normal, em XML, servir de interface com um sistema legado, etc, etc , etc
