DAOFactory

Programação Java
#1

Bom pessoal…

Não me senti confrotavel para utilizar Spring, por total ignorancia sobre a tecnologia e falta de tempo para estuda-la.
Estava tentando utilizar o Spring para injetar meu DAO no Objeto de dominio.

Ae passaram outras alternativas pela minha cabeça, uma delas seria utilizar um DAOFactory… mas pesquisando vi varias implementações, mas todas com uma quantidade muito grande de interfaces.

Meu sistema é simples e dificilmente terá seu modelo de persistencia alterado. Sera hibernate e oracle.

Minha ideia seria simplismente instanciar o DAO como um atributo estatico.
Vou colocar o codigo para simplificar:

Objeto de dominio

public class MeuObjetoD
{
    private static MeuObjetoDRepository repository = new MeuObjetoDDAO(); 
 
    .
    .
    .
}

Isso é suficiente ou ta uma mrda ?

vlw

#2

[quote=pm]Bom pessoal…

Não me senti confrotavel para utilizar Spring, por total ignorancia sobre a tecnologia e falta de tempo para estuda-la.
Estava tentando utilizar o Spring para injetar meu DAO no Objeto de dominio.

Ae passaram outras alternativas pela minha cabeça, uma delas seria utilizar um DAOFactory… mas pesquisando vi varias implementações, mas todas com uma quantidade muito grande de interfaces.

Meu sistema é simples e dificilmente terá seu modelo de persistencia alterado. Sera hibernate e oracle.

[/quote]

Se seu sistema é simples e não será alterado para quê quer um DAO ??
Não use o DAO e pronto. Acabaram seus problermas. Use só o hibernate.

#3

mas …apesar de ser simples eu quero implementar alguns conceitos de DDD.
e não quero misturar as responsabilidades das camadas, por isso eu pensei no DAO…

Entity - Repository(apenas uma interface, esta implementada pelo DAO)

DAO

#4

Dá uma procurada no GUJ que tem muito material sobre o assunto.

Mas acredito que a mensagem resumo do Philip Calçado sobre a thread que trata de DAOs nas classes de negócio resolva seu problema.

#5

[quote=pm]mas …apesar de ser simples eu quero implementar alguns conceitos de DDD.
e não quero misturar as responsabilidades das camadas, por isso eu pensei no DAO…

Entity - Repository(apenas uma interface, esta implementada pelo DAO)

[/quote]

Você tem os conceitos trocados. DAO não serve para acessar o banco de dados. DAO serve para isolar o banco de dados para que vc posssa substitui-lo mais tarde. Mas vc não quer fazer isso, logo vc não precisa do DAO.

Vc quer ter camadas , tudo bem. Mas vc não precisa do DAO.
Não complique o que é simples. Construa os seus repositórios e use o Hibernate diretamente. Vc terá uma camada
e isolamento sem precisar de DAO desde que só use o hibernate dentro dos repositórios.

#6

A idéia do Data Access Object não é de isolar, só, o banco de dados, mas qualquer repositório de dados do resto do sistema.
A implementação de uma classe DAO, é a explicação do DataMapper, de Martin Fowler. A idéia é ter uma classe responsável por persistir a entidade de domínio.

Ninguém precisa de um padrão de projeto/design. Mas eles ajudam a resolver problemas recorrentes no desenvolvimento de software. Neste caso, onde colocar a lógica de persistência.

[quote=sergiotaborda] Não complique o que é simples. Construa os seus repositórios e use o Hibernate diretamente. Vc terá uma camada
e isolamento sem precisar de DAO desde que só use o hibernate dentro dos repositórios. [/quote]

Acredito que haja um mal-entendido entre o conceito de DAO e Repositório. Recomendo fortemente a leitura do tópico sugerido anteriormente.

#7

A idéia do Data Access Object não é de isolar, só, o banco de dados, mas qualquer repositório de dados do resto do sistema.
A implementação de uma classe DAO, é a explicação do DataMapper, de Martin Fowler. A idéia é ter uma classe responsável por persistir a entidade de domínio.

Ninguém precisa de um padrão de projeto/design. Mas eles ajudam a resolver problemas recorrentes no desenvolvimento de software. Neste caso, onde colocar a lógica de persistência.
[/quote]

Isso que vc está dizendo faria sentido se não estivesse sendo usado hibernate e se não tivesse sido declarado que não vão existir mudanças no sistema de persistencia. O sistema de persistencia é o proprio hibernate que é algo muito mais evoluido que um DAO. Portanto, além de ser redundante e redutor o uso do DAO com hibernate e DDD é trabaho duplicado (ou triplicado até).
Enfim, cada caso é um caso, e no caso em epigrafe o DAO não se aplica.

[quote]

[quote=sergiotaborda] Não complique o que é simples. Construa os seus repositórios e use o Hibernate diretamente. Vc terá uma camada
e isolamento sem precisar de DAO desde que só use o hibernate dentro dos repositórios. [/quote]

Acredito que haja um mal-entendido entre o conceito de DAO e Repositório. Recomendo fortemente a leitura do tópico sugerido anteriormente.[/quote]

Isso já foi debatido aqui ad nauseum. Quem quiser saber a diferença basta fazer uma busca no GUJ.
O ponto é que dadas as directivas do projeto do colega:

  1. Sistema de persistencia baseado no hibernate e sem necessidade de alteração futura e
  2. Baseado DDD com o uso de Repositorios

O DAO é redundante , inutil, um empecilho, Enfim, uma má escolha de arquitetura.

#8

Cria o seu DAO como uma classe e cria nele um getInstancia
aih vc naum vai precisar da injeção de um objeto eh só
chamar o metodo do objeto getInstancia da classe DAO
que vc criou.

[code]public class ContatoDao {
private static ContatoDao instancia = new ContatoDao();
private static SessionFactory factory;

private ContatoDao() {
}

public synchronized static ContatoDao getInstancia() {
    if (factory == null) {
        try {
            factory = new Configuration().configure().buildSessionFactory();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    return instancia;
}[/code]

Aih eh soh usar
ContatoDao.getInstancia().saveorUpdate(contato);

#9