�ltimas mensagens do t�pico "Duvidas sobre o pattern DAO!"

Duvidas sobre o pattern DAO!

Vini Fernandes — GMT

Gostaria de saber se para realizar operacoes CRUD os metodos das minhas DAOs podem ser declarados como static. Tenho essa duvida pois estou com um projeto "bem pequeno" e nao terei necessidade de recorrer a heran�as entre as DAOs, sendo assim, n�o vejo o porque continuar programando pensando nos objetos j� que para mim � mais interessante entender os metodos como pertencentes a classe e nao ao objeto, consequentemente, declara-los como static! Resumindo: gostaria que minhas DAOs se parecessem como classes utilitarias.

Obrigado.

Re:Duvidas sobre o pattern DAO!

tnaires — GMT

Sinceramente, se o projeto for pequeno mesmo, acho que nem de DAO voc� precisa.

Re:Duvidas sobre o pattern DAO!

Vini Fernandes — GMT

Entao cara, mas eu posso ou nao declarar meu metodos como static?? Isso rompe com a defini��o do pattern DAO?

Re:Duvidas sobre o pattern DAO!

tnaires — GMT

Voc� n�o deveria se importar com isso cara, use o que for mais adequado ao seu projeto. Ficar nessa neura de seguir ou n�o seguir os padr�es ao p� da letra atrapalham muito as tomadas de decis�o.

Mas j� que isso � t�o importante, fa�a-se a seguinte pergunta: qual a fun��o do DAO? Depois fa�a a pr�xima pergunta: se eu tornar os m�todos est�ticos, meu DAO vai deixar de desempenhar a fun��o que determinei na pergunta anterior?

Detalhes de implementa��o de um padr�o n�o deveriam ser mais importantes que o conceito. A gangue dos quatro ilustrou o uso dos padr�es de projeto com uma das linguagens mainstream da �poca - C++ - que n�o possu�a o conceito de interfaces, apenas de classes abstratas. A literatura atual ilustra exemplos em Java e em C# de utiliza��o de padr�es que usam interfaces ao inv�s de classes abstratas. A� eu pergunto: um Strategy que usa interfaces ou enumerations deixou de ser um Strategy s� porque a defini��o tomada como refer�ncia utilizava classes abstratas?

Resumindo: se voc� v� que � o melhor - e n�o h� ningu�m melhor que voc� mesmo pra decidir isso - escreva seu DAO com m�todos static e seja feliz.

Re:Duvidas sobre o pattern DAO!

mateusprado — GMT

Se vc pensar na utilizacao de um metodo static em um DAO, nao vejo problemas ao usar. E � umas das formas mais adequadas de criar os metodos em seu DAO.
Mas pense um pocuo tb no que o tnaires disse.

[ ]s,

Re:Duvidas sobre o pattern DAO!

paulofafism — GMT

Bem eu n�o costumo usar m�todos estaticos nos meu DAOs, e tamb�m n�o criu v�rias quantidade de DAOs para cada objeto de n�gocio, tais como, ClienteDAO, ProdutoDAO. etc.... Eu tenho um DAO generico com diversos m�todos.

eu tenho uma classe abstrata chamada SimpleDAO e uma classe concreta chamada HibernateDAO. Durante todo meu projeto utilizo essa classe generica caso eu precisar de algum recurso especifico eu fa�o uma composi��o de classe ao inves de heran�a.

Abra�os

Re:Duvidas sobre o pattern DAO!

sergiotaborda — GMT

[quote=Vini Fernandes] Entao cara, mas eu posso ou nao declarar meu metodos como static?? Isso rompe com a defini��o do pattern DAO?[/quote]

Sim!!!!!!!
Se vc est� pensando em usar m�todos est�ticos vc ainda nem sabe o que � um DAO.

Um DAO � um [u]objeto[/u], logo, n�o pode feito com m�todos est�ticos.

Quanto � que voc�s v�o entender que n�o existe essa historia de "projeto pequeno" ?
Acha que porque o projeto � "pequeno" tem o direito a fazer cambiarra ? N�o!

E projeto nunca s�o pequenos. Eles come�am pequenos. Nunca ouviu falar em evoluir o software?

Pense grande e use os padr�es como deve ser. Se n�o sabe usar os padr�es, aprenda ; ou ent�o n�o os use.

Re:Duvidas sobre o pattern DAO!

sergiotaborda — GMT

[quote=mateusprado]Se vc pensar na utilizacao de um metodo static em um DAO, nao vejo problemas ao usar. E � umas das formas mais adequadas de criar os metodos em seu DAO.
[/quote]

??? o qu� ?? Uma das formas mais adquadas ? De onde raios saiu isso ? Se existem formas desadequadas essa ganha de longe de todas as outras.

O DAO para come�o de conversa � um servi�o definido por uma interface! n�o ha como colocar m�todos est�ticos em interfaces. Apenas isso j� deveria servir de pista para concluir que DAOs n�o se definem com m�todos est�ticos!

Ali�s m�todos est�ticos n�o devem ser usados. � o tipo de coisa que apenas os profissionais podem usar , do tipo "n�o fa�a isto em casa". Eles s�o perigosos e n�o s�o OO. Isso � outra pista para concluir que DAOs n�o se definem com m�todos est�ticos.

DAOs n�o se definem com m�todos est�ticos.

Re:Duvidas sobre o pattern DAO!

sergiotaborda — GMT

[quote=paulofafism]
eu tenho uma classe abstrata chamada SimpleDAO e uma classe concreta chamada HibernateDAO.
[/quote]

Porqu� em pleno seculo XXI quase 2010 as pessoas ainda fazem isto ?

Ser� assim t�o dif�cil entender que se o Hibernate � usado n�o ha como modificar o sistema para utilizar outro DAO apenas alterando a classe ?

Quem n�o acredita, experimente! Tente implementar um DAO JDBC puro com a mesma interface que o HibernateDAO. Boa Sorte!

N�o se enganem. Isso s� cria um monte de interfaces e classes a mais no projeto. Totalmente desnecess�rias.

Quem usa o Hibernate ou JPA nem deveria pensar em usar DAO. De quem � a culpa do uso do DAO estar t�o enraizado nas m�s pr�ticas de programa��o atuais ?

Re:Duvidas sobre o pattern DAO!

mateusprado — GMT

http://books.google.com.br/books?id=1dx34EMVyi8C&dq=dao+patterns+martin+fowler&printsec=frontcover&source=bl&ots=1v_wl3TK9H&sig=QU6UjNpiMX3lpTgT4_bb5pFsRf8&hl=pt-BR&ei=kHwHSp_MLIeJtgfGv_WRBw&sa=X&oi=book_result&ct=result&resnum=1#PPP1,M1

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Re:Duvidas sobre o pattern DAO!

paulofafism — GMT

[quote]Porqu� em pleno seculo XXI quase 2010 as pessoas ainda fazem isto ?

Ser� assim t�o dif�cil entender que se o Hibernate � usado n�o ha como modificar o sistema para utilizar outro DAO apenas alterando a classe ?

Quem n�o acredita, experimente! Tente implementar um DAO JDBC puro com a mesma interface que o HibernateDAO. Boa Sorte!
[/quote]

Ai que voc� se engana meu amigo. Logico que da sim para utilizar outro DAO, tanto Hibernate, JPA ou JDBC e eu fiz a mesma coisa que vc fez implementei um DAO usando JDBC e outro usando JPA, para testar a flexibilidade da aplica��o caso eu mudasse de tecnologia. E funcionou perfeitamente e oolha que minha classe DAO tem diversos m�todos. Eu n�o saio inst�nciando meus objeto diretamente em minha aplica��o:

[code]SimpleDAO dao = new HibernateDAO();[/code]

Ao inv�s disso tenho uma classe Factory

[code]SimpleDAO dao = DAOFactory.getDAO(AplicationContext.getContext());[/code]

A classe [b]ApplicationContext[/b] e a classe onde da inicio ao meu sistema startando as configura��es principais. basta so eu alterar essa classe e pronto. Posso alterar para outro contexto de aplica��o usando DAO, JPA ou JDBC.
Basta apenas usar a classe SimpleDAO que � abstrata.

[quote]N�o se enganem. Isso s� cria um monte de interfaces e classes a mais no projeto. Totalmente desnecess�rias.

Quem usa o Hibernate ou JPA nem deveria pensar em usar DAO. De quem � a culpa do uso do DAO estar t�o enraizado nas m�s pr�ticas de programa��o atuais ?[/quote]

Monta de interfaces? N�oo � para tanto. Para que vou criar uma interface chamada ClienteDAO, ProdutoDAO, ForncedorDAO, Ai depois voc� vem criando classes concretas para cada interface e por ai vai.... Isso sim n�o tem necessidade de criar, falta de tempo tremenda.

Re:Duvidas sobre o pattern DAO!

fantomas — GMT

Sr. [b]Vini Fernandes[/b],

Utilizar m�todos estaticos em DAOs n�o � uma boa id�ia.

E realmente, como j� disseram antes, � melhor pensar que o software ser� grande um dia. O software "pequeno" � apenas uma chance de vc ter o controle e uma visbilidade maior sobre o que est� sendo feito; isto � bom porque vc pode ver / manipular os detalhes da tecnologia com maior facilidade.

Normalmente as pessoas come�am a se interessar pelos m�todos estaticos pelo fato de vc poder submeter execu��es a partir de qualquer lugar do software; complicou um pouco o fluxo a pessoa logo j� escreve MeuQueridoDao.arrumaTudoAi() e pronto.
N�o sei se esse � o seu caso, se for saiba que isso causa desestrutura��o no software fazendo com a aplica��o da OO seja muito fraca.

flws

Re:Duvidas sobre o pattern DAO!

sergiotaborda — GMT

[quote=paulofafism][quote]Porqu� em pleno seculo XXI quase 2010 as pessoas ainda fazem isto ?

Ser� assim t�o dif�cil entender que se o Hibernate � usado n�o ha como modificar o sistema para utilizar outro DAO apenas alterando a classe ?

Quem n�o acredita, experimente! Tente implementar um DAO JDBC puro com a mesma interface que o HibernateDAO. Boa Sorte!
[/quote]

Ai que voc� se engana meu amigo. Logico que da sim para utilizar outro DAO, tanto Hibernate, JPA ou JDBC e eu fiz a mesma coisa que vc fez implementei um DAO usando JDBC e outro usando JPA, para testar a flexibilidade da aplica��o caso eu mudasse de tecnologia. E funcionou perfeitamente e oolha que minha classe DAO tem diversos m�todos. Eu n�o saio inst�nciando meus objeto diretamente em minha aplica��o:

[code]SimpleDAO dao = new HibernateDAO();[/code]

Ao inv�s disso tenho uma classe Factory

[code]SimpleDAO dao = DAOFactory.getDAO(AplicationContext.getContext());[/code]

A classe [b]ApplicationContext[/b] e a classe onde da inicio ao meu sistema startando as configura��es principais. basta so eu alterar essa classe e pronto. Posso alterar para outro contexto de aplica��o usando DAO, JPA ou JDBC.
Basta apenas usar a classe SimpleDAO que � abstrata.
[/quote]

Blz. E como vc trabalha com transa��es? acaso os seus DAOs abrem transa��es ou vc tem algum outro objeto que controla isso ?
E como vc substitui o uso de Open Session in View ?

Re:Duvidas sobre o pattern DAO!

Rubem Azenha — GMT

[quote=sergiotaborda]
Quem usa o Hibernate ou JPA nem deveria pensar em usar DAO. [/quote]

Tenta mockar a API do Hibernate ou do JPA para voc� ver como � excelente a sua decis�o arquitetural de n�o usar DAOs.

Re:Duvidas sobre o pattern DAO!

sergiotaborda — GMT

[quote=Rubem Azenha][quote=sergiotaborda]
Quem usa o Hibernate ou JPA nem deveria pensar em usar DAO. [/quote]

Tenta mockar a API do Hibernate ou do JPA para voc� ver como � excelente a sua decis�o arquitetural de n�o usar DAOs.[/quote]

?

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.

O DAO por outro lado � plug�vel, � flexivel, � gen�rico e n�o depende do dominio onde o sistema � usado.

� muito simples n�o usar o DAO, sobretudo quando usa o Hibernate ou o JPA ( que s�o DomainStores).

Agora vc pode argumentar que os "daos" que o povo usa por ai s�o na realdiade repositorios. Isso n�o � verdade. N�o respeitam o mesmo padr�o.
� como dizer que um objeto apenas com m�todos est�ticos � um DAO s� porque ele se chama xxxDAO. Ou que um factory � um singleton porque se chama "xxxxxSingleton". Isto � um argumento absurdo.
A compara��o t�m que ser feita com base no padr�o. O padr�o DAO � um subtipo do Padr�o Service. Existe a necessidade de ter um contrato separado da implementa��o. Isso faz sentido porque o DAO � flexivel e plug�vel. Para um Repositorio isso n�o faz qualquer sentido j� que ele n�o � um servi�o.

Re:Duvidas sobre o pattern DAO!

leandronsp — GMT

[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.

Re:Duvidas sobre o pattern DAO!

sergiotaborda — GMT

Re:Duvidas sobre o pattern DAO!

luistiagos — GMT

[quote=sergiotaborda][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.
[/quote]

Ser independente do dom�nio e da persist�ncia � imposs�vel. Essa afirma��o precisa de de um exemplo que a comprove. [/quote]

Eu tbm.... nunca vi esta fa�anha...

Re:Duvidas sobre o pattern DAO!

clone_zealot — GMT

Re:Duvidas sobre o pattern DAO!

leandronsp — GMT

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:

[code]
public interface RepositorioInterface () {
public void adicionar(T objeto);
public void remover(T objeto);
public List listarTodos();
}
[/code]

Um factory Interface para definir os repositorios mais especificos:

[code]
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
}
[/code]

Um repositorio interface mais especifico, que extende o RepositorioInterface:

[code]
public interface ArquivoRepositorioInterface extends RepositorioInterface {
public List getArquivosDestaque();
}
[/code]

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

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

public List getArquivosDestaque() {
// queries para retornar o desejado
}
[/code]

Neste caso estou utilizando a persistencia com JPA. Meu DaoFactory � implementado da seguinte forma:
[code]
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
}
[/code]

Na aplica��o o objeto do tipo RepositorioFactoryInterface faz os trabalhos de persist�ncia:

[code]
RepositorioFactoryInterface factory = new DaoFactory();
List arquivos = factory.getArquivoRepositorio().getArquivosDestaque();
[/code]

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).

Re:Duvidas sobre o pattern DAO!

sergiotaborda — GMT

Estava indo bem at� que ...

[quote=leandronsp]
At� agora, minhas interfaces de repositorio foram independentes da persistencia.
A partir de agora, a implementa��o do Dao (infra-estrutura para persist�ncia):

[code]
public class ArquivoRepositorioDao extends Dao implements ArquivoRepositorioInterface {

[/code]
[/quote]
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:

[code]
public class Pedido extends HashMap
[/code]

ou

[code]
public class Produtos extends ArrayList
[/code]

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.

Re:Duvidas sobre o pattern DAO!

mochuara — GMT

[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.

Re:Duvidas sobre o pattern DAO!

mochuara — GMT

[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:

[code]
public interface RepositorioInterface () {
public void adicionar(T objeto);
public void remover(T objeto);
public List listarTodos();
}
[/code]

Um factory Interface para definir os repositorios mais especificos:

[code]
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
}
[/code]

Um repositorio interface mais especifico, que extende o RepositorioInterface:

[code]
public interface ArquivoRepositorioInterface extends RepositorioInterface {
public List getArquivosDestaque();
}
[/code]

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

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

public List getArquivosDestaque() {
// queries para retornar o desejado
}
[/code]

Neste caso estou utilizando a persistencia com JPA. Meu DaoFactory � implementado da seguinte forma:
[code]
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
}
[/code]

Na aplica��o o objeto do tipo RepositorioFactoryInterface faz os trabalhos de persist�ncia:

[code]
RepositorioFactoryInterface factory = new DaoFactory();
List arquivos = factory.getArquivoRepositorio().getArquivosDestaque();
[/code]

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?

Re:Duvidas sobre o pattern DAO!

leandronsp — GMT

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:

[code]
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
}
[/code]

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

Re:Duvidas sobre o pattern DAO!

fantomas — GMT

[b]leandronsp[/b]

D� uma lida neste link [url]http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html[/url], 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

Re:Duvidas sobre o pattern DAO!

sergiotaborda — GMT

[quote=leandronsp]
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?).
[/quote]

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

[quote]
No meu caso, como utilizo o Repository, eu injetaria o EntityManager nas minhas classes de neg�cio do Repository?
[/quote]

Sim. Exactamente.

[quote]
Se for dessa forma, n�o fica parecendo um DAO, s� que com outro nome?
[/quote]

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.

Re:Duvidas sobre o pattern DAO!

leandronsp — GMT

[quote=fantomas][b]leandronsp[/b]

D� uma lida neste link [url]http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html[/url], 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
[/quote]

valeu fantomas...vou trabalhar mais essas t�cnicas ensinadas

Re:Duvidas sobre o pattern DAO!

leandronsp — GMT

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.

Re:Duvidas sobre o pattern DAO!

mochuara — GMT

[img]http://java.sun.com/blueprints/corej2eepatterns/Patterns/images09/figure09_07.jpg[/img]

Criar repositorio para DAOs � criar abstra��es em cima de abstra��es, totalmente desnecess�rio IMO.

Re:Duvidas sobre o pattern DAO!

sergiotaborda — GMT

[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.