Duvidas sobre o pattern DAO!

Assuntos Gerais Agile
#21

Estava indo bem até que …

Outch! Se eu tivesse um centavo por cada vez que alguem confundo repositorio com DAO, estaria rico.

Veja bem o problema. O repositorio não é um DAO, nem o DAO é um repositorio. Logo, herança ou implementação de um pelo outro é asneira.

Este erro é muito comum pela mesma razão que é muito comuma alguem fazer este erro aqui:

public class Pedido extends HashMap<Integer, ItemPedido>

ou

public class Produtos extends ArrayList<Produto>

As pessoas ainda não sabem o que é herança. A regra é simples: perfira composição a herança. Apenas e quando A é B é que a herança pode ser usada. (Herança aqui inclui o implements e o extends)

Ora da mesma forma que um Pedido não é um HashMap e sim Pedido contém um Map, também Repositorio não é um DAO, Repositorio contém um DAO.

Inverter as coisas é ainda pior. Fazer DAO extends Repositorio é do mesmo calibre que fazer HashMap extends Pedido. Pedido é do dominio, Map é de infra. infra não pode extender o dominio. O dominio não pode extender a infra. O que pode acontecer é que o dominio use a infra. Daqui a composição ao invés da herança.

Pior ainda é escrever um DAO usando JPA por baixo… JPA é orientado ao dominio. DAOs não são. Você não precisa usar a camada de DAO se usa JPA.

Por amor de Deus, pessoal, estudem a arquitetura JPA e o padrão Domain Store. É triste vos ver cometendo o mesmo erro vezes sem conta…

A partir do ponto que vc misturou tudo não só você não sabe no “mato sem cachorro” em que se está metendo como você ainda sofre do sindrome de DAO. Pelo menos vc ainda vislumbra uma diferença entre DAO e Repositório. Isso já é um bom sinal para um cura possivel.

#22

[quote=leandronsp][quote=sergiotaborda]
?

Em uma arquitetura sã vc tem serviços que invocar métodos em repositorios.
Os repositorios criam as pesquisas e as executam. Se vc usa o hibernate ou o JPA vc invoca-os directamente de dentro do repositorio.
O repositorio não é plugável, não é flexivel, não é genérico e depende fortemente do dominio do sistema onde é usado.
[/quote]

Eu utilizo Repositorio e a aplicação é extremamente flexível, fica independente do domínio e da persistência.
A programação com repositorio, se bem utilizada, fica bem facil de ser compreendida, podendo permitir vc criar varios metodos de consulta e dar manutenção.[/quote]

Eu utilizo Interfaces e a aplicação é extremamente flexível, fica independente do domínio e da persistência.
A programação com Interfaces, se bem utilizada, fica bem facil de ser compreendida, podendo permitir vc criar varios metodos de consulta e dar manutenção.

#23

[quote=leandronsp]Desculpem, creio que me equivoquei em dizer que o repository fica independente do dominio. Ele faz parte do dominio. Qdo desenvolvo o dominio, eu tbm crio os repositorios.
Mas ainda entendo que ele é independente da persistencia. Vou tentar demonstrar:

public interface RepositorioInterface<T> () {
   public void adicionar(T objeto);
   public void remover(T objeto);
   public List<T> listarTodos();
}

Um factory Interface para definir os repositorios mais especificos:

public interface RepositorioFactoryInterface {
   public void beginTransaction();
    public void commit();
    public void flushAndClear();    
    public void rollback();
    public void close();
   public ArquivoRepositorioInterface getArquivoRepositorio(); // aqui é definido o método para retornar um ArquivoRepositorio
}

Um repositorio interface mais especifico, que extende o RepositorioInterface:

public interface ArquivoRepositorioInterface extends RepositorioInterface<Arquivo> {
   public List<Arquivo> getArquivosDestaque();
}

Até agora, minhas interfaces de repositorio foram independentes da persistencia.
A partir de agora, a implementação do Dao (infra-estrutura para persistência):

public class ArquivoRepositorioDao extends Dao<Arquivo> implements	ArquivoRepositorioInterface {
   public ArquivoRepositorioDao(EntityManager em, RepositorioFactoryInterface factory) {
		super(em, Arquivo.class, factory);
   }

   public List<Arquivo> getArquivosDestaque() {
		// queries para retornar o desejado
   }

Neste caso estou utilizando a persistencia com JPA. Meu DaoFactory é implementado da seguinte forma:

public class DaoFactory implements RepositorioFactoryInterface {
   protected final EntityManager em;
   private EntityTransaction transaction;

   public DaoFactory() {
        em = JPAUtil.getEntityManager();
    }

    public void beginTransaction() {
        this.transaction = em.getTransaction();
        this.transaction.begin();
    }

    // demais metodos a serem implementados da interface
}

Na aplicação o objeto do tipo RepositorioFactoryInterface faz os trabalhos de persistência:

RepositorioFactoryInterface factory = new DaoFactory();
List<Arquivo> arquivos = factory.getArquivoRepositorio().getArquivosDestaque();

Não sei se ficou claro, mas eu entendo que mesmo que eu altere minha forma de persistência (no caso, trocar o JPA por qq outra coisa), não afeta as lógicas de persistência no repositório (eu só alteraria meu Dao). [/quote]

O uso de interfaces no DAO é a forma como o padrão foi projetado originalmente. O que as interfaces com prefixo Repositório que você utilizou têm de especial que a fazem levar o nome pomposo de Padrão Repositório?

#24

Sérgio,

Obrigado pelas críticas. Todas são mto bem-vindas.
A idéia do DAO nesta aplicação é justamente ele fazer os CRUDS. E o DAOFactory iniciar transações do JPA, comitar, etc.

Obviamente, nota-se na classe DAO os métodos que fazem os trabalhos de persistência utilizarem o EntityManager. Ficou uma coisa meio óbvia, e cheguei a pensar: “pra quê ter DAO, se tudo isso parece feijão com arroz ‘duas vezes’?”.

Entendi oq vc quis dizer, e pesquisando melhor em foruns, no seu blog inclusive, em links recomendados, percebi que o EntityManager do JPA e o Session do Hibernate poderiam ser os “DAO´s” da aplicação (certo?). No meu caso, como utilizo o Repository, eu injetaria o EntityManager nas minhas classes de negócio do Repository? Algo como:

class RepositorioCRUD () {
   private EntityManager em;

   // construtor que recebe o EntityManager
   public RepositorioCRUD () {
      em = JPAUtil.getManager();
   }

   public void adicionar (Object o) {
      this.em.persist(o);
   }

   // outros metodos de persistencia omitidos e getters
}

Se for dessa forma, não fica parecendo um DAO, só que com outro nome?
Obrigado.

#25

leandronsp

Dá uma lida neste link http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html, nele tem esta definição data pelo autor que pode lhe ajudar.

[quote=Debasish Ghosh]
The main differences between the Repository and the DAO are that :

* The DAO is at a lower level of abstraction than the Repository and can contain plumbing codes to pull out data from the database. We have one DAO per database table, but one repository per domain type or aggregate.

* The contracts provided by the Repository are purely "domain centric" and speak the same domain language.[/quote]

Não deixe de ler o post do cara (Debasish Ghosh) acho que irá melhora um pouco mais o seu entendimento além de dar outras idéias.

flws

#26

Certo!
Só lembrando que realmente o EntityManager é uma implementação do padrão DomainStore.
O Session do Hibernate é uma implementação do padrão UnitOfWork

Sim. Exactamente.

Não. Isso é um erro comum. Se X e Y parecem ter a mesma interface então X é Y. não!
Para X ser Y ele precisa ter não apenas a mesma interface como a mesma responsabilidade.

DAOs e Repositorios têm responsabilidades diferentes , portanto é impossivel confundi-los.

#27

[quote=fantomas]leandronsp

Dá uma lida neste link http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html, nele tem esta definição data pelo autor que pode lhe ajudar.

valeu fantomas…vou trabalhar mais essas técnicas ensinadas

#28

hum… parece que ficou mais clara essa divisão de responsabilidades. Creio que esta aplicação não foge mto doq vcs estão colocando, porém com algumas ressalvas, tais como utilizar mais composição (ao invés de herança) e fazer meu domínio enxergar a interface do repositorio apenas, e não um “dao”. Realmente pra essas coisas eu não tinha me atentando mto. Vou estudar mais o material do Evans - DDD.

O lance aqui então é: a interface do meu repositorio deve ser como um “contrato”, numa linguagem fácil para fazer parte do domínio.
A implementação do meu repositorio “contém” a infra-estrutura para persistência, neste caso o JPA.

#29

Criar repositorio para DAOs é criar abstrações em cima de abstrações, totalmente desnecessário IMO.

#30

[quote=mochuara]
Criar repositorio para DAOs é criar abstrações em cima de abstrações, totalmente desnecessário IMO.[/quote]

Isso seria verdade ser existisse uma relação 1-1. Como a relação é 1-N então isso não se aplica.

Uma entidade X tem um repositorio. Mas X é um agregado de Y, Z , … etc… logo o repositorio de X utiliza o DAO de Y, Z, etc…

A aplicação vê apenas um repositorio e o X. Mas por baixo dos panos muitas entidades estão implicitas e muitos DAOs.
Contudo, hoje em dia o DAO é desnecessário. Utilizando qualquer domain Store voce tem uma relação N-1. Vários repositorios chamam o mesmo DomainStore (porque ele não é por entidade e sim por dominio).

Veja-se como se vir, devido a que nunca existe uma relação 1-1 entre repositorios e DAOs / DomainStore , a abstração não é desnecessária.

#31