interface GenericDAO é uma necessidade?

[Adert]

Olá, pessoal

Estou mexendo num projeto que usa JPA e o padrão DAO. Já li em alguns blogs que usar DAO em um projeto JPA não é algo necessário, pois a própria JPA já representa uma abstração da camada de persistência, o que eu concordo. Mas alguns optam por manter o uso do DAO por uma questão de organização do código, o que também concordo.

Voltando ao projeto, o que me deixa intrigado é que além da JPA, de uma classe GenericDAO, dos DAOs das entidades que precisam de consultas que vão além daquelas fornecidas pelo GenericDAO ainda há, também, uma interface GenericDAO. Qual a necessidade dessa interface?

Na minha opinião fica parecendo um exagero de boas práticas(aquela de programar pensando em interfaces). Pra mim parece estranho ter uma interface de algo genérico. Isso não seria redundante?

Gostaria de ler a opinião de vocês. Sou praticamente um iniciante e posso estar tirando conclusões precipitadas.

[carlos timoshenko rodrigues lopes]

pessoalmente nessa situação eu considero o DAO como um anti-pattern. Você esta abstraindo algo que já foi abstraído, se torna uma camada desnecessária.

​

--
Você está recebendo esta mensagem porque se inscreveu no grupo "CEJUG" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.
Para postar neste grupo, envie um e-mail para ce...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/cejug.
Para obter mais opções, acesse https://groups.google.com/d/optout.

[Chris Allen Barroso]

Boas thiago.
N acho que seja propriamente um exagero usar o Dao, como vc mesmo dias são boas práticas de programação que não podemos desconsiderar quando estamos programando em um projeto que outros podem vir a intervir. Como sabe vc pode descrever tudo em uma mesmo classe esquecendo das boas práticas mas tenha em mente q provavelmente ninguém vai querer ver seu código. Quanto ao interface creio que é muito opcional porém da um
Pouco mais de segurança ao teu código.
Vamos esperar mais opiniões dos colegas.

Chris Allen Barroso

[Charles Queiroz]

Que segurança? 

Charles Queiroz

---

Dazen™  IT Services
Technology - Software Development 
cha...@dazen.com.br
Fortaleza - CE
Phone: +55 (85) 9786 8562

[Chris Allen Barroso]

Quis dizer segurança na questão da obrigatoriedade. Vc obriga os desenvolvedores a implementarem os métodos descritos na interface.

Chris Allen Barroso

--
Você recebeu essa mensagem porque está inscrito no grupo "CEJUG" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.

Para postar nesse grupo, envie um e-mail para ce...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/cejug.
Para mais opções, acesse https://groups.google.com/d/optout.

[Adert]

Valeu pelo retorno, pessoal. É Sempre bom ler outras opiniões.

E gostaria de esclarecer que não acho o uso padrão DAO um exagero. A minha crítica está em usar uma interface GenericDAO para em seguida implementá-la, como se uma classe  GenericDAO já não fosse flexível o suficiente.

[Joaquim Pedro C. Oliveira]

Oi, pessoal.

Pensando rapidamente, vejo três vantagens em se isolar o uso do JPA em uma camada separada:

1. Facilitar o teste unitário da camada de negócio, pois fica mais fácil isolar o acesso ao JPA;
2. Encapsular a biblioteca que está sendo utilizada, mantendo sua aplicação mais flexível, como nos ensinou o Uncle Bob no capítulo 8 do Clean Code;
   
3. Transformar consultas mais complexas em métodos com nomes significativos. Se você encapsular essas consultas num método privado da classe de negócio, ela começa a ficar com muita responsabilidade e pouca coesão.

Meus 2 centavos,

Joaquim

Em 2 de março de 2015 19:51, Adert <thiago.f...@gmail.com> escreveu:

Valeu pelo retorno, pessoal. É Sempre bom ler outras opiniões.

E gostaria de esclarecer que não acho o uso padrão DAO um exagero. A minha crítica está em usar uma interface GenericDAO para em seguida implementá-la, como se uma classe  GenericDAO já não fosse flexível o suficiente.

--

[Fred Farias]

Bom dia, Ardet.

Veja que a classe GenericDAO, "assinou" um contrato com a interface GenericDAO. Para entender melhor, vamos renomear a classe GenericDAO para GenericJpaDAO. Ou seja, eu tenho uma implementação da Interface Genérica utilizando JPA.

Mas imagine que em determinado momento essa solução não é mais suficiente o banco de dados não suporta mais e vocês resolvem fazer um teste migrando para um banco NoSQL (apenas um exemplo, vamos abstrair os cuidados e impactos dessa decisão).

Então podemos fazer um GenericNoSQLDAO implements GenericDAO.

Se o restante foi bem implementado, pouquíssima coisa será necessário para que o projeto continue funcionando normalmente, pois foi projetado para usar a interface.

Será que deu para compreender?

Att,
Fred Farias

[Adert]

Então, Fred Farias, é como se fosse uma precaução por não sabermos o dia de amanhã. Valeu.

    

    Joaquimpedrooliveira, você contribui foi com 2 reais :)

 

[Sergio Filho]

Em 3 de março de 2015 09:54, Fred Farias <fredm...@gmail.com> escreveu:

Bom dia, Ardet.

Veja que a classe GenericDAO, "assinou" um contrato com a interface GenericDAO. Para entender melhor, vamos renomear a classe GenericDAO para GenericJpaDAO. Ou seja, eu tenho uma implementação da Interface Genérica utilizando JPA.

Mas imagine que em determinado momento essa solução não é mais suficiente o banco de dados não suporta mais e vocês resolvem fazer um teste migrando para um banco NoSQL (apenas um exemplo, vamos abstrair os cuidados e impactos dessa decisão).

Então podemos fazer um GenericNoSQLDAO implements GenericDAO.

Se o restante foi bem implementado, pouquíssima coisa será necessário para que o projeto continue funcionando normalmente, pois foi projetado para usar a interface.

Será que deu para compreender?

Apesar de fazer bastante sentido, tenho duas considerações:

1. Na prática, qual a chance disso acontecer (mudança de tecnologia de persistência)?  

2. Mesmo que isso aconteça, usando uma IDE (ou até mesmo sem IDE), extrair uma interface de uma classe é trivial (um pouco mais trabalhoso sem IDE). Então até que se precise de uma segunda implementação, a interface não é só mais um arquivo a ser mantido (i.e. qualquer alteração nas assinaturas da classe implica em uma alteração nas assinaturas da interface)?

Em resumo, será que você vai mesmo precisar dessa interface? Ou será que é melhor deixar para tomar essa decisão com mais informação (obs: não sou muito fã do Jeff Atwood mas era o primeiro resultado no google)?

Abraços!

[Hildeberto Mendonça]

O maior problema dos design patterns é vender a idéia de "programação orientada ao futuro", ou seja, o programador nem tem o problema ainda, mas já está escrevendo uma solução para o mesmo. Ao invés de criar uma solução simples e terminar o projeto no prazo, o programador está ocupado criando uma solução para um problema que talvez jamais aconteça.

Simplifique sua vida: Ao invés de criar um DAO agora, use diretamente o JPA. Quando precisar de mais de uma fonte de dados, escreva um DAO somente para entidades implicadas.

--

Você recebeu essa mensagem porque está inscrito no grupo "CEJUG" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para ce...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/cejug.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Hildeberto Mendonça, Ph.D
Blog: http://www.hildeberto.com
Community: http://www.cejug.net
Twitter: https://twitter.com/htmfilho

[Daniel Cunha]

Eu sofro disto..
programação orientada ao futuro em alguns casos. (em fase de adaptação)

Daniel Cunha (soro)

[Davi Mustafa]

Eu acho que depende muito da necessidade de velocidade na produção da aplicação. São detalhes a serem determinados antes de começar a produção do software. 

Opinião minha claro.

Att

--
Você está recebendo esta mensagem porque se inscreveu no grupo "CEJUG" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.

Para postar neste grupo, envie um e-mail para ce...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/cejug.
Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Davi Mustafa

[carlos timoshenko rodrigues lopes]

concordo plenamente, muitas vezes os projetos terminam cheios de código praticamente inútil, e que ao longo prazo dificilmente sera alterado. No mais, se você se preocupa em mudar de tecnologia então use as especificações JPA, por que o mínimo que eu faço aqui na empresa é se for para mudar pois que mude para algo que atenda a uma especificação, sei que existem exceções, mas na regra funciona deste modo.

2015-03-04 15:05 GMT-03:00 Hildeberto Mendonça <m...@hildeberto.com>:

[Paulo Jr.]

Hildeberto, o Design Pattern em si não prevê isso, quem prevê é quem o utiliza incorretamente.

Joaquim Pedro, concordo completamente com suas palavras. Não tem haver com o futuro, mas com hoje. Quero meu negócio bem isolado e separado de qualquer código de persistência, uso DAO por isso, seja DAO/Repository/Açude/Piscina/etc ... o conceito é o mesmo e a testabilidade e isolamento ficam muito melhores.

Se você não vê impacto em usar o EntityManager na sua camada de negócio, blz, manda ver, é sua (pessoas abstrata e ninguém especificamente da lista) decisão de projeto, mas eu não quero essa "sujeira" no meu negócio que por si só já possui muitas regras.

Paulo Alves Junior

Twitter: @paulojribp

Github: http://github.com/paulojribp
Instrutor - Caelum | Ensino e Inovação

Hurraa - OpenSource project to resource management

[Hildeberto Mendonça]

2015-03-04 22:24 GMT+01:00 Paulo Jr. <paulo...@gmail.com>:

Joaquim Pedro, concordo completamente com suas palavras. Não tem haver com o futuro, mas com hoje. Quero meu negócio bem isolado e separado de qualquer código de persistência, uso DAO por isso, seja DAO/Repository/Açude/Piscina/etc ... o conceito é o mesmo e a testabilidade e isolamento ficam muito melhores.

Você terá muito mais classes no seu projeto e muito mais testes para escrever. Os testes não ficam melhores, eles ficam mais volumosos. Tudo isso por causa de uma probabilidade de mudar de fonte de dados.... num futuro que pode não chegar.

 

Se você não vê impacto em usar o EntityManager na sua camada de negócio, blz, manda ver, é sua (pessoas abstrata e ninguém especificamente da lista) decisão de projeto, mas eu não quero essa "sujeira" no meu negócio que por si só já possui muitas regras.

O custo de deixar o tal negócio "limpinho" leva tempo a dar retorno do investimento.

[Paulo Jr.]

Você terá muito mais classes no seu projeto e muito mais testes para escrever. Os testes não ficam melhores, eles ficam mais volumosos. Tudo isso por causa de uma probabilidade de mudar de fonte de dados.... num futuro que pode não chegar.

Só se você for testar o DAO, e eu não testo DAO's, não faz sentido. Pra isso existe Selenium/DBUnit/Etc... E não é pelo futuro não, é pelo agora, presente, negócio.

O custo de deixar o tal negócio "limpinho" leva tempo a dar retorno do investimento.

Que investimento? Uma classe com um método a ser invocado? Não vejo investimento pesado nisso e pra mim o retorno é imediato.

Abraço.

--

Você recebeu essa mensagem porque está inscrito no grupo "CEJUG" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para ce...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/cejug.
Para mais opções, acesse https://groups.google.com/d/optout.

[Efraim Gentil]

Concordo Paulo, a questão não é so a portabilidade mas também isolamento e a expressividade, pra mim é mais expressivo chamar um  dao.getUsuariosInvalidos() ( por exemplo ) do que um 
entityManager.createQuery("SELECT a FROM Usuario a WHERE a.invalido = true").getResultList() + logica de negocio em cima dos usuários etc.. etc.... e se minha aplicação não usar somente o JPA ? usar ibatis por exemplo, prefiro isolar todo esse acesso em um DAO

Atenciosamente,

Efraim Gentil - @efraimgentil

Github

LinkedIn

[Hildeberto Mendonça]

O Yougi tem 38 tabelas. Quantas classes a mais você adicionariam ao projeto só para ter o DAO? Por que o DAO faria diferença no Yougi?

[Rafael Uchôa]

Pessoal,

 Só pra incrementar a discussão, eu acho que a questão da explosão de DAO é devido a gente ter dois objetivos pra ele. Consultar e Manter dados. Se você tiver uma classe Repository que você add, modify e delete qualquer objeto e tem a possibilidade de fazer consultas de forma fluente, você tem o melhor dos mundos.

 Tem projetos que separam completamente essas duas lógicas, usando um Repository e um CQRS, este ultimo sendo classes somente para consultas.

ref: https://msdn.microsoft.com/en-us/library/dn568103.aspx

ref: https://msdn.microsoft.com/en-us/library/ff649690.aspx

 Eu fiz uma coisa mais simples para um projeto e criei uma classe Repository que tem os métodos de manutenção e usei o DSLQuery e faço as consultas mais simples de forma fluente no Service mesmo, mas separando em métodos pra ficar organizado. Caso a consulta, seja mais complicado, aí eu crio um Repository específico.

Ex.:

@Service
public class DSLRepositoryImpl implements DSLRepository {

    @PersistenceContext
    private EntityManager entityManager;
       
    @Override
    public <E> E add(E o) {
        entityManager.persist(o);
    }
   
    @Override
    public <E> E modify(E o) {
        entityManager.merge(o);
        return o;
    }
   
    @Override
    public <E> void delete(E o) {
        E oe = entityManager.merge(o);
        entityManager.remove(oe);
    }
   
    @Override
    public JPAQuery find() {
        return new JPAQuery(getEntityManager());
    }
   
}

Dentro do Service, agora é só criar as consultas ou usar o Repository para add alguma entidade.

@Service
public class IndicatorServiceImpl implements IndicatorService {
   
    @Autowired
    private DSLRepository repository;
   
    @Override
    public void saveIndicator(Indicator indicator) {
        repository.add(indicator);
        dataColletorJobManager.scheduleIndicator(indicator);
    }
   
    @Override
    public IndicatorUpdate findLastUpdate(Long idIndicator) {
        QIndicatorUpdate indicatorUpdate = QIndicatorUpdate.indicatorUpdate;
        return repository.find().from(indicatorUpdate)
                .where(indicatorUpdate.last.isTrue()
                        .and(indicatorUpdate.indicator.id.eq(idIndicator)))
                .singleResult(indicatorUpdate);
    }
   
}

Veja que dessa forma, eu estou com uma dependência direta com o DSLQuery. Se isso não for problema para o projeto, você tem as vantagens de consultas check-compiler, ou seja, mudanças no domain, você vai saber qual o impacto durante a compilação. Caso queira, você pode encapsular os métodos criando Repositories específicos e os services ficarem sem dependência de tecnologia.

As vezes é oneroso ficar criando classes durante o desenvolvimento, então eu deixo pra fazer em posteriores refactories, onde o código já está mais estável e já estou com mais conhecimento do negócio.

O java ainda está muito verboso para criar Predicates e usar como Specifications, mas o Spring Data está evoluindo bastante essa parte, assim não é necessário criar tanto, DAO's e/ou Repositories caso você use o framework.

ref: http://en.wikipedia.org/wiki/Specification_pattern

ref: http://spring.io/blog/2011/04/26/advanced-spring-data-jpa-specifications-and-querydsl/

ref: http://info.michael-simons.eu/2014/09/24/creating-specification-instances-for-spring-data-jpa-with-spring-mvc/

[Hildeberto Mendonça]

É mais ou menos assim que ocorre no Yougi. Nesse seu caso, apesar do PersistenceContext estar encapsulado, você continua tendo alto acoplamento com o QueryDSL porque as classes Q* sao fortemente acopladas a esse framework. Sem falar que JPASubQuery e BooleanBuilder vao aparecer mais cedo ou mais tarde nas consultas. Eu nao acho isso ruim porque esta é a realidade atual do teu projeto, assim como é a realidade atual do Yougi. O problema é o malabarismo que se faz em projetos Java para evitar esse encapsulamento sem levar em conta o custo de manter dezenas ou centenas de outras classes.

[Efraim Gentil]

Muito bacana o Spring Data com os Specifications não conhecia ainda, mas ai levanto a seguinte questão, estamos dando exemplos de query simlpes, e query mais complexas envolvendo 5 6 7 ... 10 tabelas ? Queries que não retornem entidades mas sim VO's ?  vocês seguiriam a mesma ideologia ? isso não estaria poluindo o service ? 

[Hildeberto Mendonça]

2015-03-05 12:55 GMT+01:00 Efraim Gentil <efraim...@gmail.com>:

Muito bacana o Spring Data com os Specifications não conhecia ainda, mas ai levanto a seguinte questão, estamos dando exemplos de query simlpes, e query mais complexas envolvendo 5 6 7 ... 10 tabelas ? Queries que não retornem entidades mas sim VO's ?  vocês seguiriam a mesma ideologia ? isso não estaria poluindo o service ? 

A query do exemplo retorna entidades anotadas com @Entity do JPA. As classes com prefixo Q* servem apenas para a construcao das consultas fortemente tipadas.

[Rafael Ponte]

Olá amigos,

Eu fui um dos caras que questionou sobre a real necessidade de DAOs alguns anos atrás. Apesar deles fazerem sentido no momento adequado, eu os acho desnecessários quando se trata de CRUDs. No geral um Service para gerenciar o controle transacional que chama a EntityManager diretamente é mais que suficiente. Mas isso não quer dizer que não podemos utilizá-los para melhorar a coesão e legibilidade do código, eu faço muito isso!

O importante a se pensar antes de criar um DAO ou qualquer camada de indireção é: diminuir acoplamento, aumentar coesão e simplificar a escrita de testes automatizados!

Existem outros motivos, mas no geral eu me oriento por estes acima!

Um abraço!

--

Você recebeu essa mensagem porque está inscrito no grupo "CEJUG" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para ce...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/cejug.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Rafael Ponte

TriadWorks | Formação Java
http://cursos.triadworks.com.br

[Daniel Cunha]

Quando eu olho para isto:
http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html

Bom.. meu EntityManager, ele sabe salvar/alterar/selecionar/apagar
Ele sabe interpretar queries.

Então eu me pergunto:
Pra quê eu criaria um DAO?
O que eu teria no meu DAO?

Daniel Cunha (soro)

[carlos timoshenko rodrigues lopes]

Bem, não sou arquiteto (no sentido correto da palavra) pois vejo pessoas que se autodenominam arquitetos mais que na verdade não deveriam ser assim chamados. Eu não uso mais DAO, para mim é uma abstração em algo que já foi abstraído. é o mesmo que usar SOAP em detrimento de Restful, você só esta "encharcando". realmente é uma camada duplicada.

agora se você não usa JPA, se usa JDBC puro então crie o seu DAO, pois se um dia quiser mudar de Oracle para SQL Server (kkk ou vice-e-versa) você terá um pouco menos de dor de cabeça.

e veja que no exemplo anterior a dor de cabeça também vem do fato de não usar padrões de mercado, porque se você usar sintaxe ANSI SQL, então praticamente não precisará fazer refatorações nestes tipos de mudanças.

mais, enfim apesar de nossa área ser de exatas, isso é muito pessoal, mais parece artes, ou você gosta, ou não.

abs,

2015-03-05 10:36 GMT-03:00 Rafael Ponte <rpo...@gmail.com>:

[Davi Mustafa]

Mas caras, vocês estão pensando só em entidades com CRUD's? E se a entidade tiver mais coisas além de um CRUD só? Então porque não juntar logo tudo relacionado a DAO em uma interfaceDAO. Acaba que não tem como escapar disso. 

Mas é como o Rafael falou, se for CRUD, tudo bem, mas no geral não é só CRUD.

--
Você está recebendo esta mensagem porque se inscreveu no grupo "CEJUG" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.

Para postar neste grupo, envie um e-mail para ce...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/cejug.
Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Davi Mustafa

[Rafael Ponte]

Oi Carlos,

Mesmo utilizando padrão SQL ANSI ainda assim é necessário se preocupar bastante com portabilidade. Se com JPA e Hibernate já temos essa preocupação, imagina trabalhando com SQL e JDBC.

[Virgilio Ximenes]

Responsabilidade e coesão.

Em 5 de março de 2015 11:18, Daniel Cunha <danie...@gmail.com> escreveu:

--
Você está recebendo esta mensagem porque se inscreveu no grupo "CEJUG" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.

Para postar neste grupo, envie um e-mail para ce...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/cejug.
Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Atenciosamente,

Virgílio Rocha Ximenes

[carlos timoshenko rodrigues lopes]

Eu vejo que no fim tudo é crud, as "complexidades"  devem ficar na camada de negocio, agora o papel do DAO é para fazer a conexão do modelo com o banco, se o seu DAO esta complexo então acredito que você está ferindo as camadas da sua arquitetura.

em se tratando de banco as únicas coisas que podemos fazer é inserir/consultar/alterar/excluir, validações diversas para mim se chama de regra de negócio.

mais, como disse antes, não sou arquiteto.

abs

[Daniel Cunha]

David,

pode exemplenficar isto:

Mas é como o Rafael falou, se for CRUD, tudo bem, mas no geral não é só CRUD.

DAO não são apenas CRUDS... OK.. Mas podes exemplificar isto? :)

2015-03-05 11:34 GMT-03:00 carlos timoshenko rodrigues lopes
<carlostimoshenk...@gmail.com>:

Best regard,
Daniel Cunha (soro)

[Fabrício Cabral]

Eu não sei onde vi, mas li em algum lugar que um grande percentual

(acho que era 90%) das aplicações existentes hoje, sã, no fundo,

CRUDs.

Mas não sei a veracidade disso e não sei no que ele se baseou para

dar esta informação.

At.te.

--fx

[Fabrício Cabral]

@Daniel,

até onde eu saiba (me corrijam se estiver enganado) o EntityManager é

uma abstração do padrão Domain Store [1] que por sua vez usa o DAOs.

Seria algo como EntityManager <-> DomainStore <-> DAO.

At.te.

[1] http://www.corej2eepatterns.com/DomainStore.htm

--
Você está recebendo esta mensagem porque se inscreveu no grupo "CEJUG" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.

Para postar neste grupo, envie um e-mail para ce...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/cejug.
Para obter mais opções, acesse https://groups.google.com/d/optout.

--

--fx

[Efraim Gentil]

Então minha camádo de negocio vai virar uma classe gigantesca para englobar todas as consultas mais complexas da minha entidade, sem contar com os métodos propriamente ditos que irão realizar o negocio da aplicação. Por que meu serviço deveria se preocupar com o acesso aos dados, por mais que isso esteja "abstraido" por JPA, Hibernate , eu vou precisar montar consultas, hql, criterias gigantescas para algo mais complexo, faria sentido o negocio se preocupar com montagem de queries para acessar os dados? 

[Daniel Cunha]

Fabrício,

ainda não conseguir identificar onde foi dito que padrão o
EntityManager implementa.

[Davi Mustafa]

E consultas em arquivos e coisas do tipo? A camada de negócio também ficaria responsável por isso? Acredito que DAO englobe regras além de operações em banco de dados. Não tenho tanta experiência pra afirmar isso, mas vale a pergunta.

Em 5 de março de 2015 12:31, Davi Mustafa <musta...@gmail.com> escreveu:

Eu acabei falando errado. Mas o que eu quis dizer foi, vamo dizer que a gente queira deixar de usar o DAO por só querer usar as abstrações da JPA e pronto certo?

Posso ta errado, mas exemplo de sistema que eu tenho aqui que usa tanto JPA, como JDBC e Criteria. Como faria? Não seria melhor ter tudo no DAO pra organizar melhor?

--

Davi Mustafa

--

Davi Mustafa

[Davi Mustafa]

@Soro

Eu acabei falando errado. Mas o que eu quis dizer foi, vamo dizer que a gente queira deixar de usar o DAO por só querer usar as abstrações da JPA e pronto certo?

Posso ta errado, mas exemplo de sistema que eu tenho aqui que usa tanto HQL, como JDBC e Criteria. Como faria? Não seria melhor ter tudo no DAO pra organizar melhor?

Em 5 de março de 2015 11:42, Daniel Cunha <danie...@gmail.com> escreveu:

--

Davi Mustafa

[Virgilio Ximenes]

É isso que eu digo quando falo responsabilidade.

Vale lembrar também do famoso code smell, se a classe tem muita responsabilidade, tem alguma coisa errada.

A ideia do DAO é justamente separar as responsabilidades.

Em 5 de março de 2015 12:31, Davi Mustafa <musta...@gmail.com> escreveu:

Eu acabei falando errado. Mas o que eu quis dizer foi, vamo dizer que a gente queira deixar de usar o DAO por só querer usar as abstrações da JPA e pronto certo?

Posso ta errado, mas exemplo de sistema que eu tenho aqui que usa tanto JPA, como JDBC e Criteria. Como faria? Não seria melhor ter tudo no DAO pra organizar melhor?

Em 5 de março de 2015 11:42, Daniel Cunha <danie...@gmail.com> escreveu:

--

Davi Mustafa

--
Você recebeu essa mensagem porque está inscrito no grupo "CEJUG" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para ce...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/cejug.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Atenciosamente,

Virgílio Rocha Ximenes

[Efraim Gentil]

Reduces Code Complexity in Business ObjectsBecause the DAOs manage all the data access complexities, it simplifies the code in the business objects and other data clients that use the DAOs. All implementation-related code (such as SQL statements) is contained in the DAO and not in the business object. This improves code readability and development productivity.

fonte: http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

O link também fala sobre o esforço a mais necessário e os contras de usar DAO, vale a leitura =D

​

Atenciosamente,

[Fabrício Cabral]

@Daniel,

você quer na documentação oficial? Na documentação oficial eu não

procurei, mas uma rápida busca no Google:

"The structure of the JPA EntityManager is surprisingly similar to the

Domain Store Pattern. Strictly speaking EntityManager is the realization

of the Domain Store pattern." [1]

"It is. And clearly, Java EE doesn't encourage using the DAO pattern when

using JPA (JPA already provides a standardized implementation of the

Domain Store pattern and there isn't much value at shielding it behind a DAO)." [2]

At.te.

[1] http://www.adam-bien.com/roller/abien/entry/how_to_treat_the_jpa

[2] http://stackoverflow.com/questions/3818589/java-ee-architecture-are-daos-still-recommended-when-using-an-orm-like-jpa-2

[Daniel Cunha]

Efraim,
J2EE não possui JPA. :)

Davi,
Sou de acordo com o que foi postado pelo Rafael Ponte. Por isso deixei o meu +1
Mas não consigo entender a utilização de JDBC + JPA no seu projeto.
Hora por EntityManager e horas por PreparedStatement?

[Fabrício Cabral]

@Daniel,

Agora fiquei confuso: olhando aqui: https://docs.oracle.com/javaee/7/api/toc.htm,

encontrei as APIs javax.persistance.* Elas não são do JPA?

Será que só foi foi incluido na versão 7 do J2EE?

At.te.

[Adert]

Rapaz, não imaginei que o tópico fosse render tanto. Que bom que isso aconteceu.

Algumas colocações não tenho condições de avaliar, falta o plano de fundo, mas as palavras-chave vão ficando e com o tempo assimilo melhor.

efraimgentil

Queries que não retornem entidades mas sim VO's ?

O que que significa VO's?

[Fabrício Cabral]

VO são Value Objects! :)

http://en.wikipedia.org/wiki/Value_object

http://martinfowler.com/bliki/ValueObject.html

At.te.

--
Você recebeu essa mensagem porque está inscrito no grupo "CEJUG" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para ce...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/cejug.
Para mais opções, acesse https://groups.google.com/d/optout.

--

--fx

[Daniel Cunha]

Fabrício,

Primeiro, J2EE não possui versão 7.
J2EE só existiu até a versão 1.4.
Da 5 em diante é Java EE.

http://www.oracle.com/technetwork/java/javase/overview/javanaming-2227065.html


"Make sure you use the correct term. Since May 2006 the Java EE
Platform is called only as Java EE.
Educate your users and recruiters! No more J2EE or JEE! :-)"

Chega de flammer. :P

[Daniel Cunha]

*Flamer! :P

[carlos timoshenko rodrigues lopes]

O que que significa VO's?

São classes do tipo POJO que desenvolvemos para encapsular os dados de uma entity e transportar entre processos.

2015-03-05 15:26 GMT-03:00 Adert <thiago.f...@gmail.com>:

[Davi Mustafa]

@Soro

Não é nem questão de ser boa prática. Mas ja vi projeto utilizando tanto JPA com hibernate e ainda mais JDBC com PreparedStatement.

Davi Mustafa

[Luciano da Silva Martins]

Qdo comecei com JAVA em 2010 e num possuia as anotation usava muito essas classes generic pois aprendi assim e achava de muito utilidade, hj axo q nem vira mais.

Em segunda-feira, 2 de março de 2015 15:38:32 UTC-3, Adert escreveu:

Olá, pessoal

Estou mexendo num projeto que usa JPA e o padrão DAO. Já li em alguns blogs que usar DAO em um projeto JPA não é algo necessário, pois a própria JPA já representa uma abstração da camada de persistência, o que eu concordo. Mas alguns optam por manter o uso do DAO por uma questão de organização do código, o que também concordo.

Voltando ao projeto, o que me deixa intrigado é que além da JPA, de uma classe GenericDAO, dos DAOs das entidades que precisam de consultas que vão além daquelas fornecidas pelo GenericDAO ainda há, também, uma interface GenericDAO. Qual a necessidade dessa interface?

Na minha opinião fica parecendo um exagero de boas práticas(aquela de programar pensando em interfaces). Pra mim parece estranho ter uma interface de algo genérico. Isso não seria redundante?

Gostaria de ler a opinião de vocês. Sou praticamente um iniciante e posso estar tirando conclusões precipitadas.

[Hildeberto Mendonça]

2015-03-05 15:46 GMT+01:00 Fabrício Cabral <fabri...@gmail.com>:

Eu não sei onde vi, mas li em algum lugar que um grande percentual

(acho que era 90%) das aplicações existentes hoje, sã, no fundo,

CRUDs.

Mas não sei a veracidade disso e não sei no que ele se baseou para

dar esta informação.

Pode ficar tranquilo pois essa informação é absolutamente infundada. Apps que só tem CRUDs não são apps, são tutoriais JDBC e derivados.

[Hildeberto Mendonça]

2015-03-05 16:57 GMT+01:00 Davi Mustafa <musta...@gmail.com>:

E consultas em arquivos e coisas do tipo? A camada de negócio também ficaria responsável por isso? Acredito que DAO englobe regras além de operações em banco de dados. Não tenho tanta experiência pra afirmar isso, mas vale a pergunta.

Nesse caso Davi você teria mais de uma fonte de dados, o que justificaria o DAO. Mas basta implementar o DAO para as entidades cujos dados estão em arquivos, não todas as entidades do projeto.

[Efraim Gentil]

Apesar do termo antigo, os argumentos pros e contras ainda sao validos, o que antes era escrito em native query agora virou jpql e criteria, oq me foi abstraido foi somente qual banco de dados estou usando, o que facilita a portabilidade da aplicação, mas se antes nao era escrito native query no meu service pq escrever jpql ou criteria ? Isso não gera o mesmo problema do native?

Nao estou defendendo q todo projeto deve usar DAO, pois entendo quemanter mais código não é bom, mas se tenho acesso a dados com uma complexidade maior (filtragem, predicates, vo) o padrao DAO claramente se justifica para uma separação distinta da camada de dados da complexidade do negocio, assim tenho a camada de negocio mais enxuta

--

[Google]

Acredito que se tornou um padrão usasse DAO para as classes de acesso a dados.

-- 

Att

Armando Couto 

CSM - LKU

www.armandocouto.com.br

[Rafael Uchôa]

-- troll mode on:

Era uma vez um pattern, o DAO. Ele vivia tranquilamente dentro do Core Patterns J2EE, pois nessa época só existia JDBC e as classes do tipo DTO e TO passavam livremente entre as camadas, pois assim "era bom" para o modelo anêmico herdado da especificação Java Beans.

ref: http://www.oracle.com/technetwork/java/dataaccessobject-138824.html

Depois de um tempo, frameworks foram surgidos e com isso outros personagens, assim criou-se o Entity e os pobres VO's, pobres mesmo!

Depois de ralar muito e quase virar um pokemon-bola de tanta classe DAO que era criada para cada conceito de negócio com consultas enormes e objetos Map e List voando de um  lado pro outro, o DAO perde o foco e surge o Repository, isso devido a idéias "iluministas" do Domain-Driven-Design, vulgo DDD.

Depois de um tempo, vários heróis surgem(SDO, JDO, NoSQL), como o tão esperado e discutido chamado JPA, mas com poderes já bem conhecidos e com outros faltando (Stored Procedures, Criteria, etc).

-- troll mode off.

Independente se você usa DAO/Repository/DataMapper/QueryObject, você precisa de uma classe ou camada que encapsule e centralize as consultas e se você puder deixar suas classes de negócio sem dependência de tecnologia, é melhor ainda, ou seja, sem a tal complexidade acidental.

ref: http://www.ibm.com/developerworks/library/j-eaed1/

[Paulo Jr.]

Dando aula, difícil acompanhar essa "master" discussão aqui. Bom, alguns pontos que peguei soltos por aí:

Daniel:

Quando eu olho para isto:
http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html
Bom.. meu EntityManager, ele sabe salvar/alterar/selecionar/apagar
Ele sabe interpretar queries.
Então eu me pergunto:
Pra quê eu criaria um DAO?
O que eu teria no meu DAO?

O fato dele saber disso, é ótimo, o por que, já citei no e-mail anterior e o Ponte também citou. Por isso que foi citado, isolamento do negócio, testabilidade e etc. CRUD é CRUD, não tem regras complexas ou não tem o que fazer de validação e etc, manda direto pro banco no entity manager e etc.. mas se não é CRUD simples manager.persist(), precise validar algo antes, fazer uma busca mais complexa, não vou "sujar" meu negócio com coisas JPA/Hiberante/EclipseLink. Pra isso que eu crio o DAO.

Carlos: 

Eu não uso mais DAO, para mim é uma abstração em algo que já foi abstraído. é o mesmo que usar SOAP em detrimento de Restful, você só esta "encharcando". realmente é uma camada duplicada.

DAO não é apenas uma abstração. Se você olhar por esse lado, você tem razão, não tem por que usar. Mas eu já falei no e-mail anterior, ele é isolamento de negócio, testabilidade e tudo que o Ponte também citou, que concordo.

Respondendo aos demais de maneira geral. Você falam que nem toda Entidade tem DAO, pois não tem complexidade nem necessidade, mas usam uma classe de negócio "oca" só para colocar o EntityManager e chamar manager.persist(entidade). O que me faz pensar: Pra que uma classe de negócio que só chama outra também? O DAO não se justifica, então pode que o Negócio/Service/Business/etc se justificaria? Só para chamar o EntityManger? Estou começando a achar um fundamento auto refutável.

Vendo por esse ângulo, podemos fazer uso do EntityManger no controller e deixar que o controller, ao receber a entidade CRUD faça apenas manager.persist(entidade);  ou mesmo manager.createQuery("from Usuario").getResultList();, e por aí vai. Para que o negócio se será só mais uma camada ôca? E vamos concordar né, nem toda entidade tem negócio a fazer de fato.

O DAO é um cara útil e que tem seu papel com já defendi. 

Só para usar como exemplo um projeto público  que conheço um pouco melhor, o Yougi, isso aqui pra mim é mais um DAO do que um Business, pois de negócio aí não vejo nada...

https://github.com/htmfilho/yougi/blob/master/java/src/main/java/org/yougi/business/ProvinceBean.java

https://github.com/htmfilho/yougi/blob/master/java/src/main/java/org/yougi/business/CommunityBean.java

https://github.com/htmfilho/yougi/blob/master/java/src/main/java/org/yougi/business/CityBean.java

Até essa aqui, tem muito mais cara de DAO que de negócio.. o negócio dela é umas 5 linhas....

https://github.com/htmfilho/yougi/blob/master/java/src/main/java/org/yougi/business/UserGroupBean.java

Abraço

Paulo Alves Junior

Twitter: @paulojribp

Github: http://github.com/paulojribp
Instrutor - Caelum | Ensino e Inovação

Hurraa - OpenSource project to resource management