sergiotaborda wrote:
?

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.

leandronsp wrote:

sergiotaborda wrote:
?

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.

Eu utilizo Repositorio e a aplicação é extremamente flexível, fica independente do domínio e da persistência.

sergiotaborda wrote:

leandronsp wrote:

sergiotaborda wrote:
?

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.

Eu utilizo Repositorio e a aplicação é extremamente flexível, fica independente do domínio e da persistência.

Ser independente do domínio e da persistência é impossível. Essa afirmação precisa de de um exemplo que a comprove.

sergiotaborda wrote:

leandronsp wrote:

sergiotaborda wrote:
?

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.

Eu utilizo Repositorio e a aplicação é extremamente flexível, fica independente do domínio e da persistência.

Ser independente do domínio e da persistência é impossível. Essa afirmação precisa de de um exemplo que a comprove.

leandronsp wrote:
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 {

leandronsp wrote:

sergiotaborda wrote:
?

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.

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.

leandronsp wrote: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).

Debasish Ghosh wrote:
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.

leandronsp wrote:
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?

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

fantomas wrote: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.

Debasish Ghosh wrote:
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.

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

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